From jbloom@arrl.org Fri Nov 01 11:40:08 1996
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA28714 for <hfsig@tapr.org>; Fri, 1 Nov 1996 11:40:05 -0600 (CST)
Received: from smtp_gw by mgate.arrl.org with smtp
	(Smail3.1.29.1 #9) id m0vJNZc-000f5hC; Fri, 1 Nov 96 12:40 EST
Message-Id: <m0vJNZc-000f5hC@mgate.arrl.org>
Priority: urgent
Date: Fri, 1 Nov 1996 12:38:00 -0500
From: "Bloom, Jon,  KE3Z" <jbloom@arrl.org>
Subject: FW: Wavecom W41PC DSP data decoder card
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
X-Mailer: Worldtalk (NetConnex V4.00a)/MIME


This bounced around the HQ email system until it landed in my inbox.   
Might be of interest to some on this group, I thought.

 -- Jon, KE3Z

Date: 31 Oct 96 10:02:26 EST
From: Joerg Klingenfuss <101550.514@CompuServe.COM>
To: BlindCopyReceiver:;@compuserve.com
Subject: Wavecom W41PC DSP data decoder card
Message-ID: <961031150226_101550.514_IHK54-1@CompuServe.COM>
 ----------------------------------------------------
Dear friends

we would like to draw your attention to the brandnew Wavecom W41PC DSP   
data
analyzer and decoder card for Windows 95 PC systems. This professional
equipment
is now available and it is really the ultimate decoder. We will start
distribution in early December and our "waiting list" is now open. For a
detailed description and some sample colour screenshots please refer to
http://ourworld.compuserve.com/homepages/Klingenfuss/ . A free colour   
brochure
will be available soon. Thank you for your interest, and best wishes for   
the
main listening season!

73 es best DX, Joerg Klingenfuss

Klingenfuss Radio Monitoring
Hagenloher Str. 14
D-72070 Tuebingen
Germany
Phone ++49 7071 62830
Fax ++49 7071 600849
E-Mail 101550.514@compuserve.com
WWW-Site http://ourworld.compuserve.com/homepages/Klingenfuss/


From forrerj@peak.org  Sun Nov 03 21:05:09 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA08201 for <HFSIG@TAPR.ORG>; Sun, 3 Nov 1996 21:05:07 -0600 (CST)
Received: from p01.t0.monrotel.com (p02.t0.monrotel.com [198.68.25.35]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id TAA17295 for <HFSIG@TAPR.ORG>; Sun, 3 Nov 1996 19:05:10 -0800
Message-Id: <199611040305.TAA17295@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 03 Nov 1996 19:06:41 -0800
To: HFSIG@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: DSP/Modem article

Hi,

Thought I would mention a recent article in Circuit Cellar INK
(November 1996) that may be of interest.

Page 20; "Real-Time DSP Modems with a PC and Sound Card".

Covers some experimental work on a V.22 modem that can run on a 
486 class PC with a sound card. Source code in C and assembly
are included. Interesting article if you have not yet been
introduced to modem theory and techniques.

Page 14; "Bulding a High-Performance DSP System"

Covers the architecture for the EZ-Kit. Quite informative if 
you have not used the latest ADSP-21xx family chips. Actually
the chip has a neat DMA channel that is worth something but
not given much attention in the article.

--Johan

From jsanfor@exis.net Mon Nov 04 05:42:06 1996
Received: from marlin.exis.net (root@marlin.exis.net [205.252.72.102]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA01720 for <hfsig@tapr.org>; Mon, 4 Nov 1996 05:42:05 -0600 (CST)
Received: from PENTIUM (ppp-2-58.exis.net [205.252.76.58]) by marlin.exis.net (8.7.6/8.7.3) with SMTP id GAA24342 for <hfsig@tapr.org>; Mon, 4 Nov 1996 06:42:02 -0500
Message-ID: <327DD68B.36D6@exis.net>
Date: Mon, 04 Nov 1996 06:42:03 -0500
From: Jim Sanford <jsanfor@exis.net>
Reply-To: wb4gcs@amsat.org
Organization: WB4GCS
X-Mailer: Mozilla 3.0 (Win16; U)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1687] DSP/Modem article
References: <199611040305.TAA17295@PEAK.ORG>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Johan Forrer wrote:
> 
> Hi,
> 
> Thought I would mention a recent article in Circuit Cellar INK
> (November 1996) that may be of interest.
> 
> Page 20; "Real-Time DSP Modems with a PC and Sound Card".
> 
> Covers some experimental work on a V.22 modem that can run on a
> 486 class PC with a sound card. Source code in C and assembly
> are included. Interesting article if you have not yet been
> introduced to modem theory and techniques.
> 
> Page 14; "Bulding a High-Performance DSP System"
> 
> Covers the architecture for the EZ-Kit. Quite informative if
> you have not used the latest ADSP-21xx family chips. Actually
> the chip has a neat DMA channel that is worth something but
> not given much attention in the article.
> 
> --Johan
Johan:
Not familiar with this magazine . .. where do I get one?  Is 
"Circuit Cellar" the name of the mag????

Thanks, Jim
wb4gcs@amsat.org

From rlanier@su102s.ess.harris.com  Mon Nov 04 07:42:42 1996
Received: from ess.harris.com (su15a.ess.harris.com [130.41.1.251]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA05109 for <hfsig@tapr.org>; Mon, 4 Nov 1996 07:42:41 -0600 (CST)
Received: from su102s.ess.harris.com by ess.harris.com (5.x/SMI-SVR4)
	id AA03487; Mon, 4 Nov 1996 08:42:38 -0500
Received: from Sopchoppy.GASD102designcenter by su102s.ess.harris.com (4.1/SMI-4.1)
	id AA15904; Mon, 4 Nov 96 08:42:35 EST
Received: by Sopchoppy.GASD102designcenter (SMI-8.6/SMI-SVR4)
	id IAA17814; Mon, 4 Nov 1996 08:42:32 -0500
Date: Mon, 4 Nov 1996 08:42:32 -0500
From: rlanier@su102s.ess.harris.com (Tony Lanier)
Message-Id: <199611041342.IAA17814@Sopchoppy.GASD102designcenter>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1688] Re: DSP/Modem article
X-Sun-Charset: US-ASCII

> From hfsig@tapr.org Mon Nov  4 08:00:28 1996
> Date: Mon, 4 Nov 1996 05:42:30 -0600 (CST)
> Originator: hfsig@tapr.org
> From: Jim Sanford <jsanfor@exis.net>
> To: hfsig@tapr.org
> Subject: [HFSIG:1688] Re: DSP/Modem article
> X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas
> X-Comment: Tucson Amateur Packet Radio  HF Special Interest Group
> Content-Transfer-Encoding: 7bit
> Mime-Version: 1.0
> 
> Johan Forrer wrote:
> > 
> > Hi,
> > 
> > Thought I would mention a recent article in Circuit Cellar INK
> > (November 1996) that may be of interest.
> > 
> > Page 20; "Real-Time DSP Modems with a PC and Sound Card".
> > 
> > Covers some experimental work on a V.22 modem that can run on a
> > 486 class PC with a sound card. Source code in C and assembly
> > are included. Interesting article if you have not yet been
> > introduced to modem theory and techniques.
> > 
> > Page 14; "Bulding a High-Performance DSP System"
> > 
> > Covers the architecture for the EZ-Kit. Quite informative if
> > you have not used the latest ADSP-21xx family chips. Actually
> > the chip has a neat DMA channel that is worth something but
> > not given much attention in the article.
> > 
> > --Johan
> Johan:
> Not familiar with this magazine . .. where do I get one?  Is 
> "Circuit Cellar" the name of the mag????
> 
> Thanks, Jim
> wb4gcs@amsat.org

What issue is it in? 

Tony,  KE4ATO

From sailer@ife.ee.ethz.ch Mon Nov 04 09:39:18 1996
Received: from ife.ee.ethz.ch (ife-ife1.ee.ethz.ch [129.132.25.65]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA09911 for <hfsig@tapr.org>; Mon, 4 Nov 1996 09:39:15 -0600 (CST)
Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.25.145]) by ife.ee.ethz.ch (8.8.2/8.8.2) with SMTP id QAA27156 for <hfsig@tapr.org>; Mon, 4 Nov 1996 16:38:44 +0100 (MET)
Sender: sailer@ife.ee.ethz.ch
Message-ID: <327E0E03.2783@ife.ee.ethz.ch>
Date: Mon, 04 Nov 1996 16:38:43 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Organization: IfE
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: DSP/Modem article
References: <199611040305.TAA17295@PEAK.ORG>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

While we're at implementing modems using general purpose
PC's and soundcards, some remarks from my side:

Linux 2.1.7, which was released half week ago, now
contains my packet radio drivers for general purpose
sound cards. It works with Soundblaster and WindowsSoundSystem
compatible soundcards. The drivers can do either 1200 baud AFSK
or 9600 baud G3RUH compatible FSK. Since this is Linux,
it comes with sources :-). It should be reasonnably easy
to add FEC for those who want :-)
The driver offers a network driver interface and can thus be
easily used with kernel AX.25, in theory at least. Unfortunately,
kernel AX.25 does not compile in 2.1.7 because of changes
in the user access primitives in the kernel. The drivers may
however be used by user mode ax25 stacks such as WAMPES, which
can now directly access kernel AX.25 stacks.

But to slow down your enthusiasm, here are the top 8 reasons
why a general purpose Soundcard and a PC is _NOT_ a good
signal processing platform:

1. Bad analog section of many soundcards. Frequency response
and/or noise leaves much to be desired.

2. Low resolution or sampling rates are still common. SBPro
can't do 16bits! WSS cards are somehow better...

3. A garden variety of "almost compatible" soundcards makes
life hard. Even Creative's Cards aren't fully backwards
compatible

4. Full duplex cards are still the exception. Creative's 
idea of "full duplex" operation is to stick in two soundcards.
This results in ADC and DAC sampling frequencies not being exactly
the same which may cause further difficulties depending on the
application (consider an effect processor. You just cannot output
the data sampled by one soundcard on the other soundcard, you would
have to do complicated sample rate conversions)

5. You cannot usually use the OS driver for the soundcard.
Using it would result in switching times from transmission
to reception and vice versa to be in the seconds range,
which is unacceptable for example for packet radio.
Having to drive the cards yourself exposes you to all the
braindamage of current soundcard architectures

6. It is very nontrivial to attach a time tag to each sample,
i.e. to know or specify exactly when a sample should be output.
This is needed for protocols with a rigid timing scheme, such as
{Am,Pac}Tor. This makes them virtually useless for many HF
protocols.

7. There is not one common sampling frequency every soundcard
can produce, i.e. every brand of soundcard seems to have
a distinct set of sampling frequencies available.

8. Point 7 would not be too bad if one could find out the
actual sampling frequency used. However the actual baud rate
and the rate the soundcard reports to use may differ in
the percent region! This does not matter very much for
audio, but this is bad news for example for PSK.


IMHO it boils down to:
- current soundcards have a braindamaged interface on the
  digital side
- the designers of the analog circuitry seem to be completely
  unaware of digital signal processing.
Of course there are exceptions to this rule. WSS soundcards
seem to be better because the CODEC chip comes from one
of two companies (Analog Devices or Crystal Semiconductors) that
know this field very well.

Tom
hb9jnx/ae4wa

From forrerj@peak.org  Mon Nov 04 11:54:54 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAA16752 for <hfsig@tapr.org>; Mon, 4 Nov 1996 11:54:53 -0600 (CST)
Received: from p05.t0.monrotel.com (p07.t0.monrotel.com [198.68.25.40]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id JAA01919 for <hfsig@tapr.org>; Mon, 4 Nov 1996 09:55:02 -0800
Message-Id: <199611041755.JAA01919@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 04 Nov 1996 09:56:38 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1687] DSP/Modem article

>Hi,
>
>Thought I would mention a recent article in Circuit Cellar INK
>(November 1996) that may be of interest.
  ^^^^^^^^^^^^^
Issue #76

http://www.circellar.com/

I have been an avid reader of this very down-to-earth journal
and have gained a lot from it. 

--Johan

From mcdermot@rdxsunhost.aud.alcatel.com  Wed Nov 06 14:58:24 1996
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA24005 for <hfsig@tapr.org>; Wed, 6 Nov 1996 14:58:23 -0600 (CST)
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1)
	id AA09700; Wed, 6 Nov 96 14:58:22 CST
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM (4.1/SMI-4.1)
	id AA16517; Wed, 6 Nov 96 14:58:21 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA03299; Wed, 6 Nov 96 14:58:20 CST
Date: Wed, 6 Nov 96 14:58:20 CST
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9611062058.AA03299@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: PSAM (IEEE Comm, Nov '96)



	An interesting article in the latest (Nov 96?) issue
of IEEE Communications magazine on 220 Mhz mobile data services.
It discusses multipath fading, and moving vehicles, diversity,
etc.

	One technique discussed is PSAM - Periodic Symbol Assisted
Modulation.  The transmitter sends periodically in the frame a known
symbol.  Acutally, the periodic symbol is from a set of symbols, so
the periodic symbols do not disturb the modulation stastics too much.

	Even with fast fading of driving a car, the multipath
fading is strictly band-limited.  Thus looking at the periodic symbol
gives a way to estimate the channel response, and a way to update
that estimate with time.

	There is an example of a 16-QAM constellation which is
totally useless, but when divided by the channel estimator resolves
into a 16-point constellation quite nicely.

	It would seem that this idea might be extended to HF, since
the multipath on HF is also, I think strictly band limited.   The
periodic symbol allows to compensate well for amplitude variations,
and thus may open up the possibility of the very useful QAM modulation
on HF. 16-QAM is about 4 dB more efficient, in terms of Eb/No, than
16-PSK, but it's tough on HF with the constantly changing amplitude.

	Anyone else seen this article and care to comment on whether it
might be useful on HF?




						- Tom


Tom McDermott
mcdermot@aud.alcatel.com

From zsolt@direct.ca Wed Nov 06 16:01:40 1996
Received: from aphex.direct.ca (root@aphex.direct.ca [199.60.229.6]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA26375 for <hfsig@tapr.org>; Wed, 6 Nov 1996 16:01:38 -0600 (CST)
Received: from boxer.direct.ca (van-pm-0508.direct.ca [204.174.243.128]) by aphex.direct.ca (8.8.0/8.8.0) with SMTP id OAA04520; Wed, 6 Nov 1996 14:01:28 -0800 (PST)
Date: Wed, 6 Nov 1996 15:04:15 -0800 (PST)
From: George Cserenyi <zsolt@direct.ca>
To: Tom Mcdermott <mcdermot@rdxsunhost.aud.alcatel.com>
cc: hfsig@tapr.org
Subject: Re: [HFSIG:1692] PSAM (IEEE Comm, Nov '96)
In-Reply-To: <9611062058.AA03299@eagle.aud.alcatel.com>
Message-ID: <Pine.LNX.3.91.961106144825.15342A-100000@boxer.direct.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Wed, 6 Nov 1996, Tom Mcdermott wrote among other things:
> 
> 	An interesting article in the latest (Nov 96?) issue
> of IEEE Communications magazine on 220 Mhz mobile data services.
> It discusses multipath fading, and moving vehicles, diversity,
> etc.
[...]
> 	It would seem that this idea might be extended to HF, since
> the multipath on HF is also, I think strictly band limited.   The
> periodic symbol allows to compensate well for amplitude variations,
> and thus may open up the possibility of the very useful QAM modulation
> on HF. 16-QAM is about 4 dB more efficient, in terms of Eb/No, than
> 16-PSK, but it's tough on HF with the constantly changing amplitude.
[...]
> Tom McDermott
> mcdermot@aud.alcatel.com
> 
Haven't got the chance to read that article, but found ur thoughts
on HF multipath interesting.
What practical advantage do you see by using 16-QAM modulation on HF?
What modes would it be most useful for?
What equipment is needed for HF use? Cost? Avaibility?
These are open questions to everyone on the list BTW.

I for one, would like to experiment with it.
Am long on time but short on money since retired from active work.
Is alcatel a swiss company?
73, George
ve7ciz

From alanb@polecat.sr.hp.com Wed Nov 06 19:40:44 1996
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA06483 for <hfsig@tapr.org>; Wed, 6 Nov 1996 19:40:07 -0600 (CST)
Received: from srmail.sr.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA288150802; Wed, 6 Nov 1996 17:40:03 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA052680801; Wed, 6 Nov 1996 17:40:02 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA187840801; Wed, 6 Nov 1996 17:40:01 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611070140.AA187840801@polecat.sr.hp.com>
Subject: Amplitude calibration
To: hfsig@tapr.org
Date: Wed, 6 Nov 1996 17:40:00 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) wrote:

>One technique discussed is PSAM - Periodic Symbol Assisted
>Modulation.  The transmitter sends periodically in the frame a known
>symbol.  Acutally, the periodic symbol is from a set of symbols, so
>the periodic symbols do not disturb the modulation stastics too much.

>...   The
>periodic symbol allows to compensate well for amplitude variations,
>and thus may open up the possibility of the very useful QAM modulation
>on HF. 

It sounds like a very interesting idea.  One variation would be the
following:  Rather than sending a periodic known symbol, scramble the
input data with a known pseudo-random sequence.  That would guarantee
that all possible symbol states occur at approximately equal rates.  
Then you could use AGC in the receiver to compensate for fading.  

The AGC time constant would have to be long enough to integrate enough
symbols to obtain a good average amplitude.  But the time constant would 
also have to be short with respect to the fastest fade times.  I suspect
that typical values used in HF SSB receivers would be about right, since
they have the same bandwidth ("data rate") and fading constraints.

A similar problem exists with the periodic-symbol approach -- the known 
symbol must occur much more often than the fade time, but not so often 
that it affects throughput.

A third variation would be to use both techniques together.  Scrambling
would allow receiver AGC to keep the input to the demodulator at the
optimum level for best dynamic range, while the periodic known symbol
would allow the demod to dial in a fine amplitude adjustment.

Alan Bloom N1AL

From chbrain@dircon.co.uk Thu Nov 07 01:02:57 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA25017 for <hfsig@tapr.org>; Thu, 7 Nov 1996 01:02:54 -0600 (CST)
Received: by felix.dircon.co.uk id AA04051
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 7 Nov 1996 06:59:45 GMT
Received: from gw2-115.pool.dircon.co.uk(194.112.35.115) by amnesiac via smap (V1.3)
	id sma004039; Thu Nov  7 06:59:20 1996
Message-Id: <1.5.4.32.19961107065457.0068b218@popmail.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 07 Nov 1996 06:54:57 +0000
To: hfsig@tapr.org
From: Charles Brain <chbrain@dircon.co.uk>
Subject: Re: [HFSIG:1692] PSAM (IEEE Comm, Nov '96)

>	One technique discussed is PSAM - Periodic Symbol Assisted
>Modulation.  The transmitter sends periodically in the frame a known
>symbol.  Acutally, the periodic symbol is from a set of symbols, so
>the periodic symbols do not disturb the modulation stastics too much.
>
>
Am I missing something here or are we talking about training sequencies,
if so HF serial tone modems use this technique combined with 
decision directed equalisation to update their adaptive equalisers.


Charles G4GUO  

From mcdermot@rdxsunhost.aud.alcatel.com  Thu Nov 07 13:20:07 1996
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA19923 for <hfsig@tapr.org>; Thu, 7 Nov 1996 13:20:05 -0600 (CST)
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1)
	id AA02306; Thu, 7 Nov 96 13:20:03 CST
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM (4.1/SMI-4.1)
	id AA23011; Thu, 7 Nov 96 13:20:02 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA03465; Thu, 7 Nov 96 13:20:01 CST
Date: Thu, 7 Nov 96 13:20:01 CST
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9611071920.AA03465@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Correction: PSAM (IEEE Comm, Oct '96)


	The 220 Mhz article containing (among other topics) PSAM
(Periodic Symbol-Assisted Modulation) article was in October '96
IEEE Communications magazine.  It just arrived and I assumed it
was November, sorry.


						- Tom


Tom McDermott
mcdermot@aud.alcatel.com

From mcdermot@rdxsunhost.aud.alcatel.com  Thu Nov 07 13:23:42 1996
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA20152 for <hfsig@tapr.org>; Thu, 7 Nov 1996 13:23:41 -0600 (CST)
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1)
	id AA02454; Thu, 7 Nov 96 13:23:39 CST
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM (4.1/SMI-4.1)
	id AA23101; Thu, 7 Nov 96 13:23:38 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA03471; Thu, 7 Nov 96 13:23:37 CST
Date: Thu, 7 Nov 96 13:23:37 CST
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9611071923.AA03471@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1695]


> Am I missing something here or are we talking about training sequencies,
> if so HF serial tone modems use this technique combined with
> decision directed equalisation to update their adaptive equalisers.
>
>
> Charles G4GUO
>

	I guess it depends on the definition of 'training'.  I sort
of assume that training applies to time before any data gets sent,
while PSAM applies the symbols interleaved with the data so that
variations in the channel response with time can be tracked out.
In land-line modems, the training time lets the adaptive equalizers
adapt to the channel, but if the channel varies too much and too
quickly after the data has started, the adaption cannot keep up,
and they lose it.  Normally not a problem with land-lines, but
perhaps an issue with HF.




						- Tom


Tom McDermott
mcdermot@aud.alcatel.com

From mcdermot@rdxsunhost.aud.alcatel.com  Thu Nov 07 13:29:47 1996
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA20469 for <hfsig@tapr.org>; Thu, 7 Nov 1996 13:29:45 -0600 (CST)
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/SMI-4.1)
	id AA02739; Thu, 7 Nov 96 13:29:42 CST
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM (4.1/SMI-4.1)
	id AA23257; Thu, 7 Nov 96 13:29:41 CST
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1)
	id AA03477; Thu, 7 Nov 96 13:29:41 CST
Date: Thu, 7 Nov 96 13:29:41 CST
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott)
Message-Id: <9611071929.AA03477@eagle.aud.alcatel.com>
To: hfsig@tapr.org
Subject: Re: [HFSIG:1694] Amplitude calibration


> It sounds like a very interesting idea.  One variation would be the
> following:  Rather than sending a periodic known symbol, scramble the
> input data with a known pseudo-random sequence.  That would guarantee
> that all possible symbol states occur at approximately equal rates.
> Then you could use AGC in the receiver to compensate for fading.
>
> The AGC time constant would have to be long enough to integrate enough
> symbols to obtain a good average amplitude.  But the time constant would
> also have to be short with respect to the fastest fade times.  I suspect
> that typical values used in HF SSB receivers would be about right, since
> they have the same bandwidth ("data rate") and fading constraints.
>
> A similar problem exists with the periodic-symbol approach -- the known
> symbol must occur much more often than the fade time, but not so often
> that it affects throughput.
>
> A third variation would be to use both techniques together.  Scrambling
> would allow receiver AGC to keep the input to the demodulator at the
> optimum level for best dynamic range, while the periodic known symbol
> would allow the demod to dial in a fine amplitude adjustment.
>
> Alan Bloom N1AL
>
>

	Alan: interesting idea.  There are some differences in
performance I think.  Suitably scrambled data would let you
recover phase and amplitude, any QAM modem has to do that.
You are restricted to being required to be able to differentiate
adjacent  constellation points.  In the PSAM article, adacent
constellation points could not be distuingished.  So the PSAM
symbols, being known a priori, let one derive the channel response
almost exactly even if individual constellation points are not visible.

	It was amazing to me that a single 'blob' of a constellation
could be resurrected into 16 nice constellation points just by
dividing by the computed channel response.




						- Tom


Tom McDermott
mcdermot@aud.alcatel.com

From chbrain@dircon.co.uk Thu Nov 07 14:33:42 1996
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA24469 for <hfsig@tapr.org>; Thu, 7 Nov 1996 14:33:38 -0600 (CST)
Received: by felix.dircon.co.uk id AA20646
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 7 Nov 1996 20:15:00 GMT
Received: from gw2-172.pool.dircon.co.uk(194.112.35.172) by amnesiac via smap (V1.3)
	id sma020633; Thu Nov  7 20:14:43 1996
Message-Id: <1.5.4.32.19961107201015.0067dd78@popmail.dircon.co.uk>
X-Sender: chbrain@popmail.dircon.co.uk
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 07 Nov 1996 20:10:15 +0000
To: hfsig@tapr.org
From: Charles Brain <chbrain@dircon.co.uk>
Subject: Re: [HFSIG:1697] Re: 

At 13:27 07/11/96 -0600, you wrote:
>
>> Am I missing something here or are we talking about training sequencies,
>> if so HF serial tone modems use this technique combined with
>> decision directed equalisation to update their adaptive equalisers.
>>
>>
>> Charles G4GUO
>>
>
>	I guess it depends on the definition of 'training'.  I sort
>of assume that training applies to time before any data gets sent,

Sorry retraining ! 

You want to ask Harris how they do the equalisation on their serial
tone modems.

>  Normally not a problem with land-lines, but perhaps an issue with HF.
>
 There's the rub.

>- Tom

73 Charles

From alanb@polecat.sr.hp.com Thu Nov 07 16:24:12 1996
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA00422 for <hfsig@tapr.org>; Thu, 7 Nov 1996 16:24:09 -0600 (CST)
Received: from srmail.sr.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA260575436; Thu, 7 Nov 1996 14:23:57 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA116795435; Thu, 7 Nov 1996 14:23:56 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA062285434; Thu, 7 Nov 1996 14:23:55 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611072223.AA062285434@polecat.sr.hp.com>
Subject: Amplitude Calibration
To: hfsig@tapr.org
Date: Thu, 7 Nov 1996 14:23:54 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) wrote:

>> It sounds like a very interesting idea.  One variation would be the
>> following:  Rather than sending a periodic known symbol, scramble the
>> input data with a known pseudo-random sequence.  That would guarantee
>> that all possible symbol states occur at approximately equal rates.
>> Then you could use AGC in the receiver to compensate for fading.
>
>	Alan: interesting idea.  There are some differences in
>performance I think.  Suitably scrambled data would let you
>recover phase and amplitude, any QAM modem has to do that.
>You are restricted to being required to be able to differentiate
>adjacent  constellation points.  In the PSAM article, adacent
>constellation points could not be distuingished.  So the PSAM
>symbols, being known a priori, let one derive the channel response
>almost exactly even if individual constellation points are not visible.

So the periodic known symbol is used to recover phase as well as
amplitude information?  Many QPSK systems use differential modulation
(where the data bits determine the transitions between symbol states, 
rather than the states themselves) to get around the phase ambiguity 
problem; PSAM would eliminate that requirement.  Scrambling at the 
bit rate would not do anything to recover absolute phase information.  
Another reason why using PSAM and scrambling together might be a 
synergistic solution.

> It was amazing to me that a single 'blob' of a constellation
>could be resurrected into 16 nice constellation points just by
>dividing by the computed channel response.

The clock recovery circuitry in a normal QPSK or QAM detector should
deal with any variations in the phase of the input signal.  It seems 
like the main advantage of PSAM (or scrambling) is that it can take 
out the amplitude variations as well.  

Alan Bloom N1AL

From karn@qualcomm.com Thu Nov 07 16:34:17 1996
Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA00828 for <hfsig@tapr.org>; Thu, 7 Nov 1996 16:34:15 -0600 (CST)
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by warlock.qualcomm.com (8.7.5/1.3/8.7.2/1.12) with ESMTP id OAA04888 for <hfsig@tapr.org>; Thu, 7 Nov 1996 14:32:56 -0800 (PST)
Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id OAA19910; Thu, 7 Nov 1996 14:24:34 -0800 (PST)
Date: Thu, 7 Nov 1996 14:24:34 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199611072224.OAA19910@servo.qualcomm.com>
To: Thomas Sailer <sailer@ife.ee.ethz.ch>
CC: hfsig@tapr.org
In-reply-to: <327E0E03.2783@ife.ee.ethz.ch> (message from Thomas Sailer on Mon, 4 Nov 1996 09:40:55 -0600 (CST))
Subject: Re: [HFSIG:1690] Re: DSP/Modem article

Thomas,

Thanks for your comments. They obviously come from somebody with a lot
of practical experience. Some questions of my own:

>1. Bad analog section of many soundcards. Frequency response
>and/or noise leaves much to be desired.

I agree few cards really make it to CD-quality, but is this really a
problem? I'd expect the radio and the channel to still be the limiting
factors.

>2. Low resolution or sampling rates are still common. SBPro
>can't do 16bits! WSS cards are somehow better...

Again, is this really a problem? Perhaps you can't *totally* ignore
your AF gain setting, but the achievable dynamic range should make it
pretty non-critical, at least with a 16-bit card.

BTW, in Qualcomm CDMA we routinely use 4-bit A/Ds. Analog gain
controls up front bring the signal into the limited dynamic range of
the A/Ds, which is about 24 dB. That roughly matches the processing
gain of the system, and it's plenty for an efficient coded modulation
method.

>3. A garden variety of "almost compatible" soundcards makes
>life hard. Even Creative's Cards aren't fully backwards
>compatible

Yeah, tell me about it. When I wrote my own sound driver for KA9Q NOS,
I decided to support only the SB16. I didn't consider 8-bit support to
be very important since the SB16 was already pretty cheap and seems to
have become the de-facto standard. Everybody seems to be upgrading to
them anyway, to get good quality game audio if nothing else.

>4. Full duplex cards are still the exception. Creative's 

True, but this is not a problem with half-duplex radios. Yeah, to do
digital speech you'll need a second card for the speaker/microphone,
though. Too bad it's not possible to put one SB16 channel in receive
and the other in transmit.

>5. You cannot usually use the OS driver for the soundcard.

Why is this? Buffer draining delays? Can the OS buffer size be
configured?

>6. It is very nontrivial to attach a time tag to each sample,

Yeah, I can believe this. One hack might be to tune to WWV to
calibrate both the absolute time and the sample rate. If you have good
low frequency response in the radio you can decode the 100 Hz data
stream and set the PC clock at the same time. But just doing an
autocorrelation on the data sequence ought to bring out the second
ticks and give you a pretty good idea of the sampling rate.

Question: do the soundcards typically maintain their sampling rate
once you know what it is? I note that the clock in my Pentium loses a
very consistent ~7 seconds per day, which tells me that although the
oscillator is off frequency, it's pretty stable.

>7. There is not one common sampling frequency every soundcard
>can produce, i.e. every brand of soundcard seems to have
>a distinct set of sampling frequencies available.

What are these for the SB16? The documentation implies that you can
set an almost continuous range of sample rates.

Phil

From sailer@ife.ee.ethz.ch Fri Nov 08 03:44:37 1996
Received: from ife.ee.ethz.ch (root@ife-ife1.ee.ethz.ch [129.132.25.65]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA01303 for <hfsig@tapr.org>; Fri, 8 Nov 1996 03:44:24 -0600 (CST)
Received: from eldrich.ee.ethz.ch (sailer@eldrich.ee.ethz.ch [129.132.25.145]) by ife.ee.ethz.ch (8.8.2/8.8.2) with SMTP id KAA26271; Fri, 8 Nov 1996 10:44:09 +0100 (MET)
Sender: sailer@ife.ee.ethz.ch
Message-ID: <328300E8.1F83@ife.ee.ethz.ch>
Date: Fri, 08 Nov 1996 10:44:08 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
Organization: IfE
X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m)
MIME-Version: 1.0
To: hfsig@tapr.org
CC: karn@qualcomm.com
Subject: Re: [HFSIG:1701] Re: DSP/Modem article
References: <199611072224.OAA19910@servo.qualcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> >1. Bad analog section of many soundcards. Frequency response
> >and/or noise leaves much to be desired 
> I agree few cards really make it to CD-quality, but is this really a
> problem? I'd expect the radio and the channel to still be the limiting
> factors.
Frequency response definitely _is_ a problem. Look at measurements
done by for example the c't magazine. On my laptop, I cannot monitor
G3RUH 9k6 transmissions, due to frequency response problems.
Some soundcards have a built in and not bypassable AGC, which
wreaks havoc (SBPro clones such as ESS). 
Furthermore, some soundcards (SB32, presumably also SB16) have
a not bypassable analog "equalizer" filter at the output, which can
induce unknown phase distortions. (When we tried G3RUH FSK, the
best setting of these filter was _not_ what Creative said it was
the 0dB setting)
SB cards have 3 settings for the anti aliasing filter: 3.2kHz,
8.8kHz or off. This is simply not adequate.

> >2. Low resolution or sampling rates are still common. SBPro
> >can't do 16bits! WSS cards are somehow better...> 
> Again, is this really a problem? Perhaps you can't *totally* ignore
> your AF gain setting, but the achievable dynamic range should make it
> pretty non-critical, at least with a 16-bit card.
> BTW, in Qualcomm CDMA we routinely use 4-bit A/Ds. Analog gain
> controls up front bring the signal into the limited dynamic range of
> the A/Ds, which is about 24 dB. That roughly matches the processing
> gain of the system, and it's plenty for an efficient coded modulation
> method.
That depends on the system and the signal conditionig prior to the
A/D converter.
A few years ago when I played with my RTTY decoders, the 8bit
soundcard version performed poorly compared to the TI DSK version
(14bit A/D). On HF, if you want to do part of the filtering
digitally, it requires much more than 8 bit resolution.
If you had an analoguely filtered and gain controlled signal,
8bit would be enough, but you presumably would not want to do that,
because good (read with a constant group delay) analog filters
are _extremely_ expensive.
BTW note that the gain controllable amplifier should be controlled
by the demodulator! When I did some experiments with heavily coded
low speed DPSK on HF, week signal performance was often much better
when I turned off the transceivers AGC and adjusted by myself.
AGC circuits of contemporary HF transceivers may be adequate for
SSB, but aren't for digital modes.

> >3. A garden variety of "almost compatible" soundcards makes
> >life hard. Even Creative's Cards aren't fully backwards
> >compatible> 
> Yeah, tell me about it. When I wrote my own sound driver for KA9Q NOS,
> I decided to support only the SB16. I didn't consider 8-bit support to
> be very important since the SB16 was already pretty cheap and seems to
> have become the de-facto standard. Everybody seems to be upgrading to
> them anyway, to get good quality game audio if nothing else.
Well, here I do not agree. I even got questions that wondered why
my 9k6 RUH driver does not work with SB2! SBPro is still much more
common than SB16. Anyway I quite dislike SB, see my above comments
on the analog section of the card.
Creative tells us that the only way to do "high speed" (read above
13kSamples/s) AD on SBPro is the highspeed dma command, which
according to creative's SDK does not exist on SB DSP 4 (SB16 and SB32).
SB DSP 4 however has different commands for 8bit DMA, which in
turn do not work on SBPro.
However, when I lately tried the highspeed dma commands on an SB32,
it seemed to work. But this is guesswork...

> >4. Full duplex cards are still the exception. Creative's
> 
> True, but this is not a problem with half-duplex radios. Yeah, to do
Oh yes it is. If full duplex would be common, I would have done
some HF modes (Amtor,Pactor) already some time ago. It would make
these HF things much easier.

> >5. You cannot usually use the OS driver for the soundcard.
> Why is this? Buffer draining delays? Can the OS buffer size be
> configured?
As long as you're only receiving (or only transmitting :-))
there is no problem using the OS drivers. But as soon as you'll
have to switch transmission directions in the 10ms region, you're
on your own.
Under Linux, you cannot normally reduce the buffer size to a reasonnably
low value. There is however a method to specify and map the DMA
buffer into the applications address space, but this API is very
complex. And besides, this requires that your process gets scheduled
immediately, which is at least not the case with the 'interactive'
scheduler that is the default. Maybe this works with the realtime
(POSIX.1b) extensions (sched_setscheduler), but I have to admit that
I haven't tried it. 
Under Windows, the only way to do rather low delay sound output seems
to be DirectSound, which cannot do sound input.

> >6. It is very nontrivial to attach a time tag to each sample,
> 
> Yeah, I can believe this. One hack might be to tune to WWV to
> calibrate both the absolute time and the sample rate. If you have good
> low frequency response in the radio you can decode the 100 Hz data
> stream and set the PC clock at the same time. But just doing an
> autocorrelation on the data sequence ought to bring out the second
> ticks and give you a pretty good idea of the sampling rate.
Is this 100Hz data stream modulated onto WWV? and how?
Of course there are methods to measure the sampling rate,
but how are you going to tell Joe Ham how he should do it?
Too bad if he does not own an HF radio (maybe he only wants to
do VHF/UHF) or happens to live outside the US... My neighbors
at least would definitely not like it if I built an antenna
capable of receiving WWV over here in Europe :-)
(you could say that there's DCF77 here in Europe, but there were
rumours that DCF77 would be shut down in favor of a satellite
TV subcarrier system... ok, one could also use the TV line frequency
as a reference signal)

> Question: do the soundcards typically maintain their sampling rate
> once you know what it is? I note that the clock in my Pentium loses a
> very consistent ~7 seconds per day, which tells me that although the
> oscillator is off frequency, it's pretty stable.
I haven't temperature cycled my soundcards yet, but I besides
this the sampling rate should be stable.
 
> >7. There is not one common sampling frequency every soundcard
> >can produce, i.e. every brand of soundcard seems to have
> >a distinct set of sampling frequencies available.> 
> What are these for the SB16? The documentation implies that you can
> set an almost continuous range of sample rates.
Well yes, according to the documentation, SB16 should be capable of
any integer frequency sampling rate. But I do not own one, so I cannot
tell anything about it. Besides, implementing such a codec having
decent analog performance is not so easy, and since I'm not impressed
by creative's engineering capabilities, I'm rather sceptical.
There are 'continuous rate' codecs by Analog Devices and probably
also by Crystal Semi, and since these firms know their business,
I assume their devices will perform as expected, but with creative...

I'm only talking about the sample I/O capabilities of soundcards,
other systems, such as the FM synthesizer, are IMHO of little
value to implementing communications systems.
IMHO WSS soundcards are usually better than Soundblaster and
compatible, since their main chip is an almost complete
and good soundcard on-a-chip by Analog Devices or Crystal Semi,
so card makers cannot do too much the wrong way.
And these two companies have a tradition and many years of experience
in the quality codec business. Creative's Chipsets on the other hand
leave much to be desired, especially in the audio section.

Tom

From karn@laptop Sat Nov 09 00:14:13 1996
Received: from laptop (ra4000-p38.qualcomm.com [129.46.54.118]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id AAA28212 for <hfsig@tapr.org>; Sat, 9 Nov 1996 00:14:10 -0600 (CST)
Received: by laptop
	id m0vKd0i-000MG3C
	(Debian /\oo/\ Smail3.1.29.1 #29.37); Mon, 4 Nov 96 20:21 PST
Message-Id: <m0vKd0i-000MG3C@laptop>
Date: Mon, 4 Nov 96 20:21 PST
From: Phil Karn <karn@laptop>
To: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <9611062058.AA03299@eagle.aud.alcatel.com>
	(mcdermot@rdxsunhost.aud.alcatel.com)
Subject: Re: [HFSIG:1692] PSAM (IEEE Comm, Nov '96)

Tom,

This "PSAM" stuff sounds an awful lot like training an equalizer on a
periodic known data pattern. And yes, this is a well known and widely
practiced approach to HF data, at least with high performance commercial
and military modems.

Phil

From forrerj@peak.org Wed Nov 13 16:20:50 1996
Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA26399 for <HFSIG@TAPR.ORG>; Wed, 13 Nov 1996 16:20:48 -0600 (CST)
Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id OAA09996; Wed, 13 Nov 1996 14:20:56 -0800
Date: Wed, 13 Nov 1996 14:20:56 -0800 (PST)
From: Johan Forrer <forrerj@peak.org>
X-Sender: forrerj@kira
To: HFSIG@tapr.org
Subject: Implications of SFDR
Message-ID: <Pine.SUN.3.91.961113140702.7926A-100000@kira>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi all,

Could someone please help me grasp the implications of "spurious free 
dynamic range" (SFDR).

1) Dealing with say a band 0 - 20 MHz wide, a pair of signals, 
   one at say 9.5 MHz, the other at 10 MHz, where one signal is
   significantly stronger than the other.

2) Dealing with limited number of A/D quatisation levels. What is the 
   nature of the noise model?, i.e., band limited, autoregressive, or
   whatever?

3) Does oversampling and decimation have any benifits here, i.e., if
   the A/D convertor could sample a 1 GSPS but have only 3 bits of
   resolution - what is that worth with respect to effective SFDR.


Perhaps you would recognize that these questions relate to working 
with DSP at RF rates, i.e., connecting the A/D convertor to the antenna
and hope for the best :-).

Comments, suggestions or discussion would be most helpful.

Thanks much,

--Johan, KC7WW

From 100577.1452@CompuServe.COM Thu Nov 14 14:11:59 1996
Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com [149.174.206.137]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA23906 for <HFSIG@tapr.org>; Thu, 14 Nov 1996 14:11:57 -0600 (CST)
Received: by dub-img-7.compuserve.com (8.6.10/5.950515)
	id PAA26662; Thu, 14 Nov 1996 15:11:26 -0500
Date: 14 Nov 96 15:09:02 EST
From: Mike Kerry <100577.1452@CompuServe.COM>
To: "(unknown)" <HFSIG@tapr.org>
Subject: Designing Filters
Message-ID: <961114200901_100577.1452_GHW117-1@CompuServe.COM>

I am experimenting with designing FIR filters
for HF data modes (aren't we all?) and would be
interested to hear some opinions about the important
features to be considered, e.g:-

- Blackman vs Kaiser vs other windowing functions

- choice of passband width, relating to shift and Baud rate

- perhaps stop-band width is more important than pass-band?

- length of filter, especially considering the effect on ISI

- what else?

Thanks,

Mike Kerry, G4BMK

From alanb@polecat.sr.hp.com Thu Nov 14 17:38:08 1996
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA01774 for <hfsig@tapr.org>; Thu, 14 Nov 1996 17:38:03 -0600 (CST)
Received: from srmail.sr.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA054974674; Thu, 14 Nov 1996 15:37:55 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA184654673; Thu, 14 Nov 1996 15:37:54 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA095324672; Thu, 14 Nov 1996 15:37:53 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611142337.AA095324672@polecat.sr.hp.com>
Subject: Spurious-Free Dynamic Range
To: hfsig@tapr.org
Date: Thu, 14 Nov 1996 15:37:52 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Johan Forrer <forrerj@peak.org> wrote:

>Could someone please help me grasp the implications of "spurious free 
>dynamic range" (SFDR).

SFDR is defined as the ratio (usually expressed in dB) between the RMS
value of the input signal and the RMS value of the largest spurious 
frequency component.  The value depends on the signal waveform, usually 
a full-scale sine wave.  It gets worse the higher the frequency.  
If the signal consists of two sine waves, the test is usually called 
"two-tone intermodulation distortion" (two-tone IMD) rather than SFDR.

>1) Dealing with say a band 0 - 20 MHz wide, a pair of signals, 
>   one at say 9.5 MHz, the other at 10 MHz, where one signal is
>   significantly stronger than the other.

Data sheet IMD specs assume the two signals are of equal amplitude.
With many analog components, you can assume that third-order spurs
fall 3 dB per dB of the input signal, fifth order spurs fall 5 dB per
dB, etc.  But that's not true for A/D converters.  Sometimes the spur
actually gets stronger at lower signal levels.

>2) Dealing with limited number of A/D quatisation levels. What is the 
>   nature of the noise model?, i.e., band limited, autoregressive, or
>   whatever?

As you probably know, SFDR measures only spurs, not quantization noise.
Signal-to-noise ratio (SNR) in dB is theoretically 6*(bits resolution) 
+ 1.76 dB.  So a 12-bit A/D theoretically has 73.76 dB SNR.  Practical 
devices are typically somewhat worse than that.  

The noise is white, uniformly spread between 0 Hz and the Nyquist 
frequency.  If you look at the spectrum using a 1024-point FFT, the 
noise will appear 10*log(1024) = 30 dB lower since each frequency
point represents only 1/1024 of the total quantization noise.

>3) Does oversampling and decimation have any benifits here, i.e., if
>   the A/D convertor could sample a 1 GSPS but have only 3 bits of
>   resolution - what is that worth with respect to effective SFDR.

With 3 bits of resolution, the SNR is theoretically 19.76 dB, spread
out between 0 and 500 MHz.  If you decimated and filtered down to
30 MHz, that would improve the SNR to 19.76 + 10*log(500/30) = 32 dB.
Usually, what people do is use delta-sigma A/D converters designed 
to shape the noise spectrum to be non-white.  If most of the noise
is pushed up in frequency, then the low-pass decimation filters can
get rid of most of it and you end up with much better SNR.

>Perhaps you would recognize that these questions relate to working 
>with DSP at RF rates, i.e., connecting the A/D convertor to the antenna
>and hope for the best :-).

Just in the last few months, new A/D converters have been introduced
by Analog Devices that make direct sampling of an entire RF band
practical.  However, they are designed for cellular applications,
where the in-band signals are well controlled.  That is, unlike the
HF amateur bands, all the signals have similar power levels, and there
are a limited number of them (<= the number of channels).  You still
need a tuned RF front end to eliminate out-of-band signals.  As I
understand it, these new A/Ds are just barely good enough even under 
these relatively benign conditions.  They are used in base-station
designs, where price is not much of an issue.

To see what the A/D is up against, consider the US cellular band,
which consists of 832 channels between 869 and 894 MHz.  I think
each A/D only has to deal with one subband ("A" band or "B" band),
which consists of 333 channels spaced 30 kHz apart.  If each of 
the incoming 333 signals were exactly the same power level, then
the total signal seen by the A/D would have a 10*log(333) = 25 dB
peak-to-average ratio.  But of course, all the signals are not
exactly the same.  And the absolute level is not all that well
controlled.  Unlike analog components, an A/D does not degrade 
gracefully when the input gets too strong -- once you exceed the 
input rails, severe distortion results.  For both those reasons 
you need to leave lots of headroom; let's say another 20 dB or so.  
That puts your signal level down around -45 dB from full scale.  

The two-tone IMD spec is not too useful in this application, since 
there are up to 333 tones to deal with.  There are many combinations 
of third, fifth, seventh, etc. order products from other channels 
that can produce a spur in a given channel.  Two in-phase,
equal-amplitude spurs together are 6 dB more powerful than either
spur alone.  Counting third-order products only, any channel will 
see 166 spurs from the other 332 channels.  The total worst-case
spur level would then be up to 20*log(167) = 44 dB stronger than 
from a single third-order intermod.  

So we're talking on the order of 90 dB SFDR for the A/D.  And as I 
recall, cellular equipment manufacturers are looking for numbers
even a little better than that.  That's right at the state of the 
art in A/D design.

To cover an amateur HF band, I think even more performance would be 
called for.  For one thing, there can be more than 333 signals on 
the band at one time.  For another, the signal levels vary all over 
the map.  You may wish to listen to a signal just above the noise 
level (around -130 dBm or so) at the same time as a contest is going 
on with multiple S9+40 dB (~-30 dBm) signals at the other end of the 

band.  You would have to adjust the RF gain so that full scale on 
the A/D is on the order of 0 dBm at the antenna terminals.  That 
implies a SFDR around 130 dB.

And that's for a single band.  It would get worse if you wanted to 
cover 0-30 MHz in one fell swoop.

In addition to spurs, quantization noise would be a problem.
Assuming a 16-bit A/D with 90 dB SNR, and a ratio of Nyquist
frequency to bandwidth of (500/3), the quantization noise in a 
3 kHz channel would be around -112 dBm, or nearly 20 dB louder 
than the signal you are trying to hear.

Still, that's a lot closer to acceptable performance than existed
a year ago.  In years to come, as A/D performance improves and 
prices fall, we may yet get all-digital radios with performance
equal to the best analog designs.

Alan Bloom N1AL

From alanb@polecat.sr.hp.com Thu Nov 14 20:59:01 1996
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA09629 for <hfsig@tapr.org>; Thu, 14 Nov 1996 20:58:58 -0600 (CST)
Received: from srmail.sr.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA043626735; Thu, 14 Nov 1996 18:58:55 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA213906734; Thu, 14 Nov 1996 18:58:54 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA233916733; Thu, 14 Nov 1996 18:58:53 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611150258.AA233916733@polecat.sr.hp.com>
Subject: FIR filters
To: hfsig@tapr.org
Date: Thu, 14 Nov 1996 18:58:53 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Mike Kerry <100577.1452@compuserve.com> wrote:

>I am experimenting with designing FIR filters
>for HF data modes (aren't we all?) and would be
>interested to hear some opinions about the important
>features to be considered, e.g:-
>
>- Blackman vs Kaiser vs other windowing functions
>
>- choice of passband width, relating to shift and Baud rate
>
>- perhaps stop-band width is more important than pass-band?
>
>- length of filter, especially considering the effect on ISI
>
>- what else?

One important feature is a Nyquist response.  A Nyquist filter is 
one where the signal trajectory passes exactly through the proper 
symbol location exactly at each decision time.  This is true no matter 
what values nearby symbols take.  i.e. there is no inter-symbol 
interference (ISI).

One common Nyquist filter is the  "Raised-Cosine."  The frequency
response is unity from zero Hz up to (1-alpha) times the cutoff
frequency and zero from (1+alpha) * Fc up to the Nyquist rate.
(Alpha is a selectable parameter that determines how sharply the
filter cuts off.)  Between (1-alpha)*Fc and (1+alpha)*Fc, the 
frequency response is half of a raised cosine (surprise!):

_______________
               '--_
                   \
                    \
                     \
                      -__
                         '-------------------  Frequency
       alpha-->|    |<--
               |    |    |
                 -->|    |<--alpha
                    |
                   Fc=1

That's the frequency response.  The impulse response in the time domain
is a weighted sinc function.  sinc(x) = (sine(PI*x))/(PI*x)  Note that
sinc(x) is zero for all non-zero integer values of x.  That means that
an impulse (one symbol) has zero effect on adjacent symbols, so there
is no inter-symbol interference.

You need a filter both in the transmitter (to reduce adjacent-channel 
interference) and in the receiver (to reject nearby signals).  Two 
Nyquist filters in series are no longer Nyquist.  So what is normally 
done is to use a "root-Nyquist" filter such as the root-raised-cosine 
filter, whose frequency response is the square root of a raised-cosine.  
In this way, the total channel response is Nyquist, so there is no net 
inter-symbol interference.  Note that the actual transmitted signal has 
lots of inter-symbol "interference."  It is only after passing through 
the matched filter in the receiver that the ISI is magically removed.

By the way, in order to have a Nyquist response, the cut-off frequency 
Fc (-3 dB point for root-Nyquist, -6 dB for Nyquist) should be at 
exactly 1/2 the symbol rate.

It is possible to use non-Nyquist filters so long as the resulting
inter-symbol interference is kept small enough not to cause a problem.
That's what is done for GMSK.  Gaussian Minimum-Shift Keying uses a
(surprise!) Gaussian filter which is non-Nyquist.  Commercial systems
that use GMSK include GSM (European digital cellular) and DECT (a 
digital cordless phone standard.)

The filter coefficients in an FIR filter are the same as the impulse
response.  Since a weighted sinc function theoretically extends from
minus infinity to plus infinity, it is obviously impossible to build a 
perfect FIR raised-cosine filter.  (The same is true of just about any 
other filter, including Gaussian.)  One solution is just to truncate 
the theoretical response so that it is short enough to fit into your 
hardware.  If you do that to a Nyquist filter, it remains Nyquist, 
since the zero-crossing points remain at the same places.  However, it 
does affect the frequency response, especially in the stopband, so you 
will get additional splatter into adjacent channels.  The shorter the 
FIR filter length, the worse the interference.  It turns out that if 
you "window" the response, rather than truncating it, the stopband 
rejection is improved.

Windowing means that the coefficients near the edges are gradually 
reduced in amplitude so that there is no abrupt transition between full 
values and the ones that have been set to zero to fit into the available 
filter width.  Many different window functions have been invented over 
the years.  The Hann window (raised cosine in the time domain) is very 
simple to implement, but only has 30 dB or so of stopband rejection.
The Hamming window (offset raised cosine) gets down to better than
-40 dB.  The Blackman window uses two superimposed raised cosines of
different periods and achieves nearly -60 dB.  There is a tradeoff
between stopband and passband performance -- typically the better the
stopband rejection the worse the passband accuracy.  The Kaiser window 
is parameterised -- by selecting the alpha factor you can optimize the
passband/stopband tradeoff.

A root-Nyquist filter does not have zero crossings at the adjacent 
symbol locations.  When you truncate or window the impulse response, 
inter-symbol interference is created.  That's why you don't necessarily
want the window with the best stop-band response -- the poorer passband
accuracy degrdades ISI.

If you want to play around with filters, there are many software programs
available.  I like to use Mathcad, even though it is not specialized
for this application.  You can choose the filter coefficients using your
favorite window (you have to know the equation for it) or other filter
design method and do an FFT on the coefficients to obtain the frequency 
response.  Or you can enter the desired frequency response and do an
inverse FFT to obtain the filter coefficients.  (Inelegant, but it works!)

You can also calculate the ISI by RMS-summing the time-response values
at all adjacent symbol locations.  (If it's a root-Nyquist filter, you
have to convolve it with an "ideal" filter first.)

I think you can get a copy of Mathcad for around $100 or so.  It is useful
for many things besides designing filters.  It is easy to learn and quite
powerful.  I can send a sample FIR filter Mathcad file to anyone interested.

Alan Bloom N1AL

From forrerj@peak.org  Thu Nov 14 21:54:50 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA12817 for <hfsig@tapr.org>; Thu, 14 Nov 1996 21:54:48 -0600 (CST)
Received: from p04.t0.monrotel.com (p01.t0.monrotel.com [198.68.25.34]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id TAA08791 for <hfsig@tapr.org>; Thu, 14 Nov 1996 19:54:47 -0800
Message-Id: <199611150354.TAA08791@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 14 Nov 1996 19:58:09 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1706] Spurious-Free Dynamic Range

Alan,

That was very helpful information - thanks a lot.

I follow the rationale - one further question. I assume IMD originates from
a non-linear process somewhere in the chain, not the quatization process;
that introduces wide-band noise. Am I right? If so, would that imply that if
we had a perfectly linear A/D convertor, and a no clipping situation, that SFDR 
ratio would become very large?

The bit about shaping digitization noise for later filtering is quite
interesting. Do you perhaps a have a reference to how that's done? 

I recently read a paper on a military radio that uses a one-bit A/D to 
sample its 2.5 MHz IF - the high linearity of this A/D attributes to a quoted 
SFDR in excess of 105 dB, which is quite usable

As I understand things then, what is needed is a very flexible tunable 
bandpass filter ahead of such a A/D. 

--Johan 



>Johan Forrer <forrerj@peak.org> wrote:
>
>>Could someone please help me grasp the implications of "spurious free 
>>dynamic range" (SFDR).
>
>SFDR is defined as the ratio (usually expressed in dB) between the RMS
>value of the input signal and the RMS value of the largest spurious 
>frequency component.  The value depends on the signal waveform, usually 
>a full-scale sine wave.  It gets worse the higher the frequency.  
>If the signal consists of two sine waves, the test is usually called 
>"two-tone intermodulation distortion" (two-tone IMD) rather than SFDR.
>
>>1) Dealing with say a band 0 - 20 MHz wide, a pair of signals, 
>>   one at say 9.5 MHz, the other at 10 MHz, where one signal is
>>   significantly stronger than the other.
>
>Data sheet IMD specs assume the two signals are of equal amplitude.
>With many analog components, you can assume that third-order spurs
>fall 3 dB per dB of the input signal, fifth order spurs fall 5 dB per
>dB, etc.  But that's not true for A/D converters.  Sometimes the spur
>actually gets stronger at lower signal levels.
>
>>2) Dealing with limited number of A/D quatisation levels. What is the 
>>   nature of the noise model?, i.e., band limited, autoregressive, or
>>   whatever?
>
>As you probably know, SFDR measures only spurs, not quantization noise.
>Signal-to-noise ratio (SNR) in dB is theoretically 6*(bits resolution) 
>+ 1.76 dB.  So a 12-bit A/D theoretically has 73.76 dB SNR.  Practical 
>devices are typically somewhat worse than that.  
>
>The noise is white, uniformly spread between 0 Hz and the Nyquist 
>frequency.  If you look at the spectrum using a 1024-point FFT, the 
>noise will appear 10*log(1024) = 30 dB lower since each frequency
>point represents only 1/1024 of the total quantization noise.
>
>>3) Does oversampling and decimation have any benifits here, i.e., if
>>   the A/D convertor could sample a 1 GSPS but have only 3 bits of
>>   resolution - what is that worth with respect to effective SFDR.
>
>With 3 bits of resolution, the SNR is theoretically 19.76 dB, spread
>out between 0 and 500 MHz.  If you decimated and filtered down to
>30 MHz, that would improve the SNR to 19.76 + 10*log(500/30) = 32 dB.
>Usually, what people do is use delta-sigma A/D converters designed 
>to shape the noise spectrum to be non-white.  If most of the noise
>is pushed up in frequency, then the low-pass decimation filters can
>get rid of most of it and you end up with much better SNR.
>
>>Perhaps you would recognize that these questions relate to working 
>>with DSP at RF rates, i.e., connecting the A/D convertor to the antenna
>>and hope for the best :-).
>
>Just in the last few months, new A/D converters have been introduced
>by Analog Devices that make direct sampling of an entire RF band
>practical.  However, they are designed for cellular applications,
>where the in-band signals are well controlled.  That is, unlike the
>HF amateur bands, all the signals have similar power levels, and there
>are a limited number of them (<= the number of channels).  You still
>need a tuned RF front end to eliminate out-of-band signals.  As I
>understand it, these new A/Ds are just barely good enough even under 
>these relatively benign conditions.  They are used in base-station
>designs, where price is not much of an issue.
>
>To see what the A/D is up against, consider the US cellular band,
>which consists of 832 channels between 869 and 894 MHz.  I think
>each A/D only has to deal with one subband ("A" band or "B" band),
>which consists of 333 channels spaced 30 kHz apart.  If each of 
>the incoming 333 signals were exactly the same power level, then
>the total signal seen by the A/D would have a 10*log(333) = 25 dB
>peak-to-average ratio.  But of course, all the signals are not
>exactly the same.  And the absolute level is not all that well
>controlled.  Unlike analog components, an A/D does not degrade 
>gracefully when the input gets too strong -- once you exceed the 
>input rails, severe distortion results.  For both those reasons 
>you need to leave lots of headroom; let's say another 20 dB or so.  
>That puts your signal level down around -45 dB from full scale.  
>
>The two-tone IMD spec is not too useful in this application, since 
>there are up to 333 tones to deal with.  There are many combinations 
>of third, fifth, seventh, etc. order products from other channels 
>that can produce a spur in a given channel.  Two in-phase,
>equal-amplitude spurs together are 6 dB more powerful than either
>spur alone.  Counting third-order products only, any channel will 
>see 166 spurs from the other 332 channels.  The total worst-case
>spur level would then be up to 20*log(167) = 44 dB stronger than 
>from a single third-order intermod.  
>
>So we're talking on the order of 90 dB SFDR for the A/D.  And as I 
>recall, cellular equipment manufacturers are looking for numbers
>even a little better than that.  That's right at the state of the 
>art in A/D design.
>
>To cover an amateur HF band, I think even more performance would be 
>called for.  For one thing, there can be more than 333 signals on 
>the band at one time.  For another, the signal levels vary all over 
>the map.  You may wish to listen to a signal just above the noise 
>level (around -130 dBm or so) at the same time as a contest is going 
>on with multiple S9+40 dB (~-30 dBm) signals at the other end of the 
>band.  You would have to adjust the RF gain so that full scale on 
>the A/D is on the order of 0 dBm at the antenna terminals.  That 
>implies a SFDR around 130 dB.
>
>And that's for a single band.  It would get worse if you wanted to 
>cover 0-30 MHz in one fell swoop.
>
>In addition to spurs, quantization noise would be a problem.
>Assuming a 16-bit A/D with 90 dB SNR, and a ratio of Nyquist
>frequency to bandwidth of (500/3), the quantization noise in a 
>3 kHz channel would be around -112 dBm, or nearly 20 dB louder 
>than the signal you are trying to hear.
>
>Still, that's a lot closer to acceptable performance than existed
>a year ago.  In years to come, as A/D performance improves and 
>prices fall, we may yet get all-digital radios with performance
>equal to the best analog designs.
>
>Alan Bloom N1AL
>
>

From 100577.1452@CompuServe.COM Fri Nov 15 14:45:56 1996
Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com [149.174.177.136]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA19189 for <HFSIG@tapr.org>; Fri, 15 Nov 1996 14:45:53 -0600 (CST)
Received: by hil-img-6.compuserve.com (8.6.10/5.950515)
	id PAA12707; Fri, 15 Nov 1996 15:45:20 -0500
Date: 15 Nov 96 15:43:45 EST
From: Mike Kerry <100577.1452@CompuServe.COM>
To: "(unknown)" <HFSIG@tapr.org>
Subject: [HFSIG:1707] FIR filters,  demodulation
Message-ID: <961115204345_100577.1452_GHW126-1@CompuServe.COM>

Thanks Alan (N1AL) for the detailed reply. One thing however,
you said:-

> You need a filter both in the transmitter (to reduce adjacent-channel 
> interference) and in the receiver (to reject nearby signals). 

Does this imply there is no point in trying to use Nyquist receive
filters when decoding sundry Amtor Pactor RTTY signals which may
have been generated by non-Nyquist-compatible means?  If so,
then what!?

Have you the time to elaborate on some phrases in your reply?
The first is "a Nyquist filter is one where the signal trajectory
passes exactly thru the proper symbol location exactly at decision
time".  What is the signal trajectory? And proper symbol location?

Also: "for a Nyquist response the cut-off frequency should be at 1/2 
the symbol rate".  

So for 100 Bd Amtor, Fc is 50 Hz ??? I don't understand. Sorry!

The second half of your message on windowing functions and Mathcad
was helpful, tnx.

If I may ask another broad question, may I elicit views on demodulation
techniques for RTTY Amtor Pactor?  e.g. FM versus AM demodulators, or
what else?

Thanks,

Mike Kerry, G4BMK

From 100577.1452@CompuServe.COM Fri Nov 15 14:45:59 1996
Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com [149.174.177.136]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA19201 for <HFSIG@tapr.org>; Fri, 15 Nov 1996 14:45:57 -0600 (CST)
Received: by hil-img-6.compuserve.com (8.6.10/5.950515)
	id PAA12755; Fri, 15 Nov 1996 15:45:24 -0500
Date: 15 Nov 96 15:43:48 EST
From: Mike Kerry <100577.1452@CompuServe.COM>
To: "(unknown)" <HFSIG@tapr.org>
Subject: [DSP:36] GCC56K
Message-ID: <961115204348_100577.1452_GHW126-2@CompuServe.COM>

Tim said:

> You can get the MS-DOS executable from

> ftp://www.mot.com/SPS/DSP/helpline/cc/dist.wpc.cc56.tar.z

Tim, I tried, but was told the page does not exist.
I searched the Motorola DSP index for GCC56K but it
found nothing.

Mike, G4BMK

From alanb@polecat.sr.hp.com Fri Nov 15 15:36:53 1996
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA02277 for <hfsig@tapr.org>; Fri, 15 Nov 1996 15:36:48 -0600 (CST)
Received: from srmail.sr.hp.com by relay.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA224013780; Fri, 15 Nov 1996 13:36:21 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA279373778; Fri, 15 Nov 1996 13:36:19 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA053593777; Fri, 15 Nov 1996 13:36:17 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611152136.AA053593777@polecat.sr.hp.com>
Subject: SFDR
To: hfsig@tapr.org
Date: Fri, 15 Nov 1996 13:36:17 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

forrerj@peak.org (Johan Forrer) wrote:

>I assume IMD originates from
>a non-linear process somewhere in the chain, not the quatization process;
>that introduces wide-band noise. 

Right, the quantization is generally modeled as white noise, although it 
can depend on the input signal.  For example, if the input is a sine wave 
a little more than one LSB in amplitude, then the quantized output will 
appear as a square wave, which looks like distortion, rather than noise.
Intuitively, if the input signal is "large" and "random" in some sense,
then the quantization error will be noise-like.

>Am I right? If so, would that imply that if
>we had a perfectly linear A/D convertor, and a no clipping situation, that 
>SFDR ratio would become very large?

That's right.  Many of the nonlinearities are dynamic effects that don't
show up with low-frequency or DC signals.  And of course, not only does the 
A/D converter have to be linear, but so does any other analog circuitry 
between the antenna and A/D input.

>The bit about shaping digitization noise for later filtering is quite
>interesting. Do you perhaps a have a reference to how that's done? 

When I get home tonight I'll check to see if the topic is covered in a
couple DSP books I have at home.

>I recently read a paper on a military radio that uses a one-bit A/D to 
>sample its 2.5 MHz IF - the high linearity of this A/D attributes to a quoted 
>SFDR in excess of 105 dB, which is quite usable

One-bit delta-sigma A/D converters tend not to have very good absolute
accuracy, but they can have very good linearity (low distortion).  That's
why they are often used in audio applications -- distortion is much more
important than gain accuracy.  The same would apply to RF applications.
However, the analog sampling rate must be much higher than the digital
output samples (and much higher than the RF bandwidth), which of course
is much harder to do at RF than at audio frequencies.

>As I understand things then, what is needed is a very flexible tunable 
>bandpass filter ahead of such a A/D. 

That would help a lot.  You would then essentially have a TRF (Tuned 
Radio Frequency) receiver like they used in the 1920's, except that the 
crystal detector is replaced by a DSP!  The other option is to do have a 
conventional superhet receiver front end with a relatively wide-bandwidth 
IF crystal filter and a digital DSP-based IF.  The DSP could implement 
variable-bandwidth bandpass filters, most of the AGC function, noise 
blanker, notch filter, and demodulator.  Compared to the all-digital 
radio, the A/D and DSP's jobs are much easier, because of the narrower 
bandwidth and reduced dynamic range requirements (assuming there is some 
analog gain control in front of the A/D.)

By the way, the sampling rate must be > 2x the bandwidth, not 2x the
frequency.  For example, if the IF frequency is 2.5 MHz, and the bandwidth
is 100 kHz, you can theoretically use sample rates as low as 200 kHz.
(Although in practice it has to be somewhat higher than that.)  With an
I/Q demodulator, sample rate must be > 1x bandwidth.

Al N1AL

From tim@acca.nmsu.edu Fri Nov 15 20:16:43 1996
Received: from acca.nmsu.edu (tim@acca.NMSU.Edu [128.123.3.58]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id UAA29230 for <hfsig@tapr.org>; Fri, 15 Nov 1996 20:16:34 -0600 (CST)
Received: from localhost by acca.nmsu.edu (8.6.12/acca-1.0)
	id TAA26642; Fri, 15 Nov 1996 19:16:30 -0700
Date: Fri, 15 Nov 1996 19:16:29 -0700 (MST)
From: Tim Baggett <tim@acca.nmsu.edu>
X-Sender: tim@acca
To: hfsig@tapr.org
Subject: Re: [HFSIG:1710] [DSP:36] GCC56K
In-Reply-To: <961115204348_100577.1452_GHW126-2@CompuServe.COM>
Message-ID: <Pine.SUN.3.95.961115191349.26474A-100000@acca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Fri, 15 Nov 1996, Mike Kerry wrote:

> Tim said:
> 
> > You can get the MS-DOS executable from
> 
> > ftp://www.mot.com/SPS/DSP/helpline/cc/dist.wpc.cc56.tar.z
> 
> Tim, I tried, but was told the page does not exist.
> I searched the Motorola DSP index for GCC56K but it
> found nothing.


How in the world did this get over to the HFSIG list??!! I thought it was
on the DSP list were I get it at work!

Anyhow, leave the filename off. I guess netscrape doesn't like a URL that
goes for the specific file. Chop it off after the /cc and you will get the
directory.

BTW, the manual gcc56kman.zip or something like that is in a stupid
FrameMaker format. I have one of the docs guys converting it over to PDF
format. They tend to think everyone in the world has Frame Maker. I never
heard of it until I started work there.

73
Tim



From alanb@polecat.sr.hp.com Fri Nov 15 20:19:22 1996
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA29656 for <hfsig@tapr.org>; Fri, 15 Nov 1996 20:19:18 -0600 (CST)
Received: from srmail.sr.hp.com by hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA082750756; Fri, 15 Nov 1996 18:19:16 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA026900755; Fri, 15 Nov 1996 18:19:15 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA208680754; Fri, 15 Nov 1996 18:19:14 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611160219.AA208680754@polecat.sr.hp.com>
Subject: More on filters
To: hfsig@tapr.org
Date: Fri, 15 Nov 1996 18:19:14 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Mike Kerry <100577.1452@compuserve.com> wrote:

>you said:-
>
>> You need a filter both in the transmitter (to reduce adjacent-channel 
>> interference) and in the receiver (to reject nearby signals). 
>
>Does this imply there is no point in trying to use Nyquist receive
>filters when decoding sundry Amtor Pactor RTTY signals which may
>have been generated by non-Nyquist-compatible means?  If so,
>then what!?

Ideally, the filters in the receiver and transmitter should be matched
so that the net response is Nyquist.  You can always find a receive
filter that accomplishes that by adding an equalizing filter whose
response is the reciprocal of transmit filter response.  (Theoretically,
anyway.)  But of course you have to know the transfer function of the 
transmit filter.

Fortunately the filters don't have to be perfect.  People got along 
fine with analog filters (inherently non-Nyquist) for years.  Of course, 
they had to make do with wider bandwidths than necessary to keep the
inter-symbol interference within reason.

>Have you the time to elaborate on some phrases in your reply?
>The first is "a Nyquist filter is one where the signal trajectory
>passes exactly thru the proper symbol location exactly at decision
>time".  What is the signal trajectory? And proper symbol location?

By "signal trajectory" I just mean a plot of signal versus time.  At 
the receiver detector (after filtering), the instantaneous value of the 
signal is measured at the decision time, once per symbol.  The possible 
symbol locations depend on the modulation type.  For FSK or BPSK, there 
are only two possibilities.  For 256 QAM, there are 16 possible symbol 
locations for the I channel and 16 for the Q channel, giving a total of 
16*16 = 256 possible symbol locations on the I/Q plane.

The job of the detector is to read the signal value at the decision
time and decide which of the possible symbol locations the signal is
closest to.  For FSK, if the symbol locations are +1 and -1, then any 
signal value above 0 is considered a +1 and anything below is a -1.

>Also: "for a Nyquist response the cut-off frequency should be at 1/2 
>the symbol rate".  
>
>So for 100 Bd Amtor, Fc is 50 Hz ??? I don't understand. Sorry!

Yes.  Theoretically, a signal doesn't need to have any energy above
1/2 the symbol rate.  Consider a 1-bit-per-symbol modulation like FSK.
The fastest you can make that signal change is to send it a continuous
series of alternating one's and zero's.  So if the baud rate is 100
symbols/sec, the unfiltered signal would be a 50 Hz square wave. 
* (See disclaimer below)  If you filtered it with a brick-wall filter 
with a cutoff at 50 Hz (i.e. a Nyquist filter with an alpha = 0), the 
square wave would be turned into a sine wave, and no information would 
be lost.  Any other combination of 1's and 0's can only have even lower 
frequency components.  For example 110011001100... has a repetition rate 
of Fs/4.

Of course, a practical filter can't have a brick-wall frequency
response.  But to be Nyquist (no inter-symbol interference), it must
be half-scale (-6 dB) at 1/2 the symbol rate and be anti-symmetrical
about that point on the frequency axis.  A raised-cosine filter is one
that fits that description.

>If I may ask another broad question, may I elicit views on demodulation
>techniques for RTTY Amtor Pactor?  e.g. FM versus AM demodulators, or
>what else?

AM demodulators are supposed to work better than FM discriminators.
Years ago, I used a Frederick Electronics demodulator quite a bit on
the HF bands.  It could be switched between FM and AM modes.  I could
never see much difference, as a practical matter.  As I recall, that
demod had circuitry to dynamically adjust the decision level of the
"slicer" (mark/space comparator), to account for selective fading
(one tone stronger than the other) and interference affecting one
frequency more than the other.  The box did indeed seem to work better
than standard designs.

Al N1AL

From beppe@ns1.dinamica.it Sat Nov 16 04:30:43 1996
Received: from ns1.dinamica.it (root@ns1.dinamica.it [194.28.13.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA06640 for <hfsig@tapr.org>; Sat, 16 Nov 1996 04:30:32 -0600 (CST)
From: beppe@ns1.dinamica.it
Received: from ilaria (ilaria.dinamica.it [194.28.13.150]) by ns1.dinamica.it (8.6.11/8.6.9) with SMTP id MAA04907 for <hfsig@tapr.org>; Sat, 16 Nov 1996 12:03:27 +0100
Date: Sat, 16 Nov 1996 12:03:27 +0100
Message-Id: <1.5.4.16.19961116113718.096fa3ea@pt.dinamica.it>
X-Sender: beppe@pt.dinamica.it
X-Mailer: Windows Eudora Light Version 1.5.4 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 1 (Highest)
To: hfsig@tapr.org
Subject: unsubscribe

======================================
Giuseppe Selvatici beppe@pt.dinamica.it
======================================

From forrerj@peak.org  Sat Nov 16 21:48:31 1996
Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id VAA27051 for <hfsig@tapr.org>; Sat, 16 Nov 1996 21:48:28 -0600 (CST)
Received: from p08.t0.monrotel.com (p08.t0.monrotel.com [198.68.25.41]) by PEAK.ORG (8.6.13/8.6.7) with SMTP id TAA02151 for <hfsig@tapr.org>; Sat, 16 Nov 1996 19:48:32 -0800
Message-Id: <199611170348.TAA02151@PEAK.ORG>
X-Sender: forrerj@peak.org
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 16 Nov 1996 19:51:57 -0800
To: hfsig@tapr.org
From: forrerj@peak.org (Johan Forrer)
Subject: Re: [HFSIG:1709] FIR filters,  demodulation

Mike,

My 2 cents on the subject;

>
>If I may ask another broad question, may I elicit views on demodulation
>techniques for RTTY Amtor Pactor?  e.g. FM versus AM demodulators, or
>what else?
>
>Thanks,
>
>Mike Kerry, G4BMK
>
>

My experience has been that a MAP receiver exhibits exceptional robustness
for HF operation. Such a MAximum Postiori receiver may be considered a
filter bank and a selector switch that selects the filter output with
largest magnitude. There are some elegant mathematics to support this, which
can be extended to produce matched filter theory.

Good adjacent channel interference is of prime importance.

With synchronous data systems, such as AMTOR and Pactor, the demodulator and
detector operation can be controlled as a byproduct from the data decoding
process. In this case a software PLL can guide the demodulator/detector to
clean up data decisions. The performance is not as good as a real coherent
demodulator, but can approach that.

A novel idea is to make use of soft-decision decoding, i.e., Viterbi
decoding to aid in bit synchronisation and data extraction. An example where
this have been done successfully is shown in the work of Dave Mills, W3HCF
where he uses such a scheme to decode RTTY and FEC AMTOR. This by itself is
worth a couple of dB and also buys further robustness.

Yes, it is possible to decode FSK using phase information, i.e., multiply
the signal by a delayed version of itself. The FSK demodulators that Pawel,
SP9VRC wrote for the EVM does this, so does the DSP93 modems of Frank
Perkins. It works reasonably well, howeber, I am of the opinion that this
technique does not show the same robustness as the filter-type approach
described above. Possibly it is a tradeoff between phase stability/ambiuity
against spectral power measurement. I suspect the latter being a more
statistically robust measure.   


Hope this helps.

--Johan, KC7WW 

From 100577.1452@CompuServe.COM Sun Nov 17 17:57:17 1996
Received: from dub-img-3.compuserve.com (dub-img-3.compuserve.com [149.174.206.133]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA29968 for <HFSIG@tapr.org>; Sun, 17 Nov 1996 17:57:16 -0600 (CST)
Received: by dub-img-3.compuserve.com (8.6.10/5.950515)
	id SAA21458; Sun, 17 Nov 1996 18:56:41 -0500
Date: 17 Nov 96 18:55:06 EST
From: Mike Kerry <100577.1452@CompuServe.COM>
To: "(unknown)" <HFSIG@tapr.org>
Subject: [HFSIG:1713] Filters and Demods
Message-ID: <961117235505_100577.1452_GHW48-1@CompuServe.COM>

Thanks to Alan and Johan for their contributions.

I have been experimenting with an FM demodulator, and
also a matched filter approach, taking the difference
in magnitude between mark and space filters (not sure if 
that constitutes an AM decoder or what. Someone is bound
to enlighten me).

The FM system is currently giving better results on higher
baud rates (e.g. 200 Bd Pactor) and the matched filter
approach is better on RTTY. (These both being compared to a
BARTG Multyterm matched filter op-amp terminal unit).

I like the idea of running multiple filters in parallel
and choosing the set that gives maximum eye-height or
difference - or of adjusting filter coefficients on the fly
to maximise.  With modes like Pactor and AX25 especially, 
with frame checking being done in the DSP too, one can run 
multiple techniques in parallel and just see which gives you a 
valid CRC for the frame.  This would be nice for monitoring
Pactor, as you can effectively be continuously running 
optimally at both 100 and 200 Bd.

With non self-checking modes like RTTY, is there a danger of
other factors like QRM affecting eye-height and confusing 
the filter choice, or is eye-height or matched filter
difference always going to be a good guide?

Can someone tell me please how to compute the optimum receive
filter pass-band width for a given Baud rate and Shift, to 
maximise legitimate energy capture. And are you talking about
3 dB or 6 dB points.

Some background information:
My DSP platform at present is a 20 MIPS TMS320C51 processor 
with TLC32044 AIC, 64K full speed SRAM and 64K Flash. I have the
TI Coff Assembler, and 'C' Compiler (rather bugged!). Main uses
to date have been for 1200 Baud FSK and 2400 Baud QPSK used
over trunked radio networks. Now looking at the HF modes. 
I am awaiting delivery of my DSP56002EVM.

73,


Mike Kerry, G4BMK

From k5cnf1@juno.com  Sun Nov 17 20:30:48 1996
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA09095 for <HFSIG@TAPR.ORG>; Sun, 17 Nov 1996 20:30:46 -0600 (CST)
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail)
	id VAA23542; Sun, 17 Nov 1996 21:30:15 EST
To: HFSIG@tapr.org
Date: Sun, 17 Nov 1996 08:15:44 PST
Subject: TU-170
Message-ID: <19961117.082836.8279.0.k5cnf1@juno.com>
X-Mailer: Juno 1.00
X-Juno-Line-Breaks: 3-5
From: k5cnf1@juno.com (Richard B Morrow)

anyone out there have any idea as to how I could put an ancient Flesher
TU-170 to use with my newer computers. The only program I have is for
the ancient Radio Shack Model 1 which is not an option to use. I have
the docs on the tu, which helps.

Richard, K5CNF

From 100577.1452@CompuServe.COM Mon Nov 18 04:52:25 1996
Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com [149.174.217.132]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA07459 for <HFSIG@tapr.org>; Mon, 18 Nov 1996 04:52:23 -0600 (CST)
Received: by arl-img-2.compuserve.com (8.6.10/5.950515)
	id FAA24198; Mon, 18 Nov 1996 05:51:53 -0500
Date: 18 Nov 96 05:50:39 EST
From: Mike Kerry <100577.1452@CompuServe.COM>
To: "(unknown)" <HFSIG@tapr.org>
Subject: [HFSIG:1717] TU-170
Message-ID: <961118105038_100577.1452_GHW47-1@CompuServe.COM>


Richard, K5CNF wrote:

>anyone out there have any idea as to how I could put an ancient Flesher
>TU-170 to use with my newer computers. The only program I have is for
>the ancient Radio Shack Model 1 which is not an option to use. I have
>the docs on the tu, which helps.

Richard, try contacting Steve, AC4IW, at Spheretron.  He can supply
the BMK-Multy software which does RTTY, Amtor and Pactor etc. on a PC
and I'm pretty sure the TU-170 is amongst TU's that have been interfaced.

Spheretron 25 Eastwood Road, P.O.Box 5964, Asheville NC 28813
Tel: (704) 274 4646

Mike, G4BMK



From w5zit@juno.com  Mon Nov 18 10:03:44 1996
Received: from x3.boston.juno.com (x3.boston.juno.com [205.231.100.22]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA18228 for <hfsig@tapr.org>; Mon, 18 Nov 1996 10:03:37 -0600 (CST)
Received: (from w5zit@juno.com) by x3.boston.juno.com (queuemail)
	id LAB28179; Mon, 18 Nov 1996 11:03:01 EST
To: hfsig@tapr.org
Subject: Re: [HFSIG:1717] TU-170
Message-ID: <19961118.110303.7879.1.w5zit@juno.com>
References: <19961117.082836.8279.0.k5cnf1@juno.com>
X-Mailer: Juno 1.15
X-Juno-Line-Breaks: 2-3,7-8,13-14,19-20,24-25,27-28,30-32
From: w5zit@juno.com (James H Brown)
Date: Mon, 18 Nov 1996 11:03:01 EST

Richard - the TU-170 was designed for 45 Baud RTTY - but has the makings
of a front end for the faster Baud rates if you do a little tinkering
with it.

Take a look at the filtering after the mark/space detector and see if the
output transitions are restricted to a slower rate.  You may have to
decrease the value of one or more filter caps to get the higher data
rates.

There are several packages that run RTTY from a PC that would require no
mod to the TU-170 at all - except for perhaps an adapter to get the
RS-232 levels conditions for your PC.  I don't recall if the I/O of the
TU-170 is RS-232 compatable or just TTL - but you probably have all the
specs there in your docs.

I have used an Amtor freebie program on HF with some success, and the
TU-170 should work well on Amtor with the Baud filter modified to pass
the 100 Baud data. On the other hand - if the Flesher specs say it was
designed to pass 100 Baud RTTY signals - then no modification would be
required for Amtor.

There is a program that can be purchased to run Pactor to an external
modem also - which would require modifying the TU-170 Baud fliter to pass
the 200 Baud Pactor signals.  I do not recall the name of the program -
but I have worked several hams using it.

Look on the QRZ CD Rom for programs that run on the PC to run various
modes.  You may have some ham buddies who have that CD who can help.

If you have trouble locating any of the specific programs - let me know
and I will see what I can dig up.

73 - Jim - w5zit@juno.com

From alanb@polecat.sr.hp.com Mon Nov 18 16:58:09 1996
Received: from paloalto.access.hp.com (daemon@paloalto.access.hp.com [15.254.56.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA07983 for <hfsig@tapr.org>; Mon, 18 Nov 1996 16:56:56 -0600 (CST)
Received: from srmail.sr.hp.com by paloalto.access.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA190247806; Mon, 18 Nov 1996 14:56:47 -0800
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA128817805; Mon, 18 Nov 1996 14:56:46 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA067387805; Mon, 18 Nov 1996 14:56:45 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611182256.AA067387805@polecat.sr.hp.com>
Subject: Sigma Delta
To: hfsig@tapr.org
Date: Mon, 18 Nov 1996 14:56:44 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I promised to try to find a reference explaining Sigma-Delta A/D converters.
None of my DSP textbooks seem to cover the topic.  I did find an app note
from Harris Semiconductor (AN9504, May 1995) that does a pretty good job.
I can copy it if anyone is interested.

Basically a sigma-delta converter is formed thus:

Analog        _________     ____________     _____________
Input  ----->|+        |   |            |   | Comparator  |
             |  Summer |-->| Integrator |-->| (1-bit A/D) |--*-> Digital
         ,-->|-________|   |____________|   |_____________|  |   Output
         |               ___________                         |
         |              |           |                        |
         '--------------| 1-bit DAC |<-----------------------'
                        |___________|

The digital output is a 1-bit signal at a high bit rate.  It then goes to 
a low-pass filter and decimator to produce an N-bit output at a lower rate.

Let's say the 1-bit DAC puts out +1V for a "1" and -1V for a "0".  
(Actually you'd probably just use a CMOS gate that puts out +5V and 0V, 
if you don't mind having a unipolar analog input.)  If the analog input
is 0V, then the feedback loop forces the digital output to be half 1's
and half 0's so that the integrator input sees half +1V and half -1V.
The output of the integrator is then a small triangle wave centered
about zero volts.  If the analog input is +0.8V (90% full scale), then 
the digital output is 90% 1's and 10% 0's.  

Because there is an integrator (-6 dB per octave frequency response) in
the feedback path, the quantization noise at the digital output has a
+6 dB/octave rising characteristic, dropping to minus infinity (zero
error) at DC.

If you are using a large oversample ratio (high sampling rate), then
the digital filter in the decimator can filter off most of that high-
frequency quantization noise.  Even though a 1-bit A/D theoretically
only has 6 + 1.76 = 7.76 dB S/N ratio, after filtering it can be
equivalent to, for example, a 16-bit A/D.  The digital filter has a
1-bit input and an N-bit output.

By using a second-order converter with two integrators, you get a
12 dB/octave frequency response.  Third-order gives 18 dB/octave, etc.

The advantage of the sigma-delta A/D is that the linearity is not
affected by nonlinearities in the internal ciruitry of a conventional 
multi-bit A/D.  Also, most of the circuitry is digital, rather than analog, 
which makes it easier to design the whole thing into a monolithic IC.

Alan Bloom N1AL

From k5cnf1@juno.com  Mon Nov 18 19:20:38 1996
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA15375 for <hfsig@tapr.org>; Mon, 18 Nov 1996 19:20:34 -0600 (CST)
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail)
	id UAB18380; Mon, 18 Nov 1996 20:13:20 EST
To: hfsig@tapr.org
Date: Mon, 18 Nov 1996 06:38:42 PST
Subject: Re: [HFSIG:1718] TU-170
Message-ID: <19961118.065406.8279.1.k5cnf1@juno.com>
References: <961118105038_100577.1452_GHW47-1@compuserve.com>
X-Mailer: Juno 1.00
X-Juno-Line-Breaks: 1-5
From: k5cnf1@juno.com (Richard B Morrow)

OK MIKE Ha! had the caps lock on, you are the second person to recommend
that program..

Thanks a lot.

Richard, K5CNF

From k5cnf1@juno.com  Mon Nov 18 19:31:19 1996
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA15872 for <hfsig@tapr.org>; Mon, 18 Nov 1996 19:31:16 -0600 (CST)
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail)
	id UAC18380; Mon, 18 Nov 1996 20:13:20 EST
To: hfsig@tapr.org

Date: Mon, 18 Nov 1996 06:43:56 PST
Subject: Re: TU-170
Message-ID: <19961118.065406.8279.2.k5cnf1@juno.com>
References: <19961118.110303.7879.1.w5zit@juno.com>
X-Mailer: Juno 1.00
X-Juno-Line-Breaks: 2-6
From: k5cnf1@juno.com (Richard B Morrow)

Ok, Jim, I know some one who has that CD.ROM. I have the capabilities of
being able to look at the signals in the TU, several scopes,so I will
check that stuff out

Thanks loads

Richard, K5CNF

From karn@qualcomm.com Mon Nov 18 20:47:58 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA19634 for <hfsig@tapr.org>; Mon, 18 Nov 1996 20:47:56 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id SAA09847; Mon, 18 Nov 1996 18:47:23 -0800 (PST)
Date: Mon, 18 Nov 1996 18:47:23 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199611190247.SAA09847@servo.qualcomm.com>

To: hfsig@tapr.org
In-reply-to: <199611170348.TAA02151@PEAK.ORG> (forrerj@peak.org)
Subject: Re: [HFSIG:1715] Re: FIR filters,  demodulation

I would like to add to Johan's and Alan's excellent comments by giving
a little fundamental theory, as it's essential in understanding their
remarks. Otherwise, all that complexity about Nyquist and raised
cosine responses seems baffling.

Two requirements must be satisfied simultaneously to maximize the
performance of a digital link.

First, the receiver filter must be "matched" to the transmitted signal
spectrum. That is, the receiver filter amplitude response must match
the amplitude of the transmitted signal spectrum. Additionally, if
there is group delay distortion (frequency-dependent delay) in the
transmitted signal, as can happen with sloppy analog filter design in
the modulator, then the matched filter should have the inverse delay
curve to compensate for the transmitter filter.

Second, the combination of the transmitter filter and the receiver
filter should have a Nyquist response, i.e., the group delay is flat
and the frequency response is anti-symmetrical around the frequency
corresponding to one-half the data rate.

The first requirement maximizes the SNR performance against noise and
interference while the second requirement minimizes self-interference,
i.e., intersymbol interference, at the important moment in the center
of each bit when you sample it. Note that the ISI is *not* zero on
either side of the correct sampling instant, which is why it's
important to have accurate clock recovery. In an eye diagram, this ISI
shows up as "jitter" in the eye on either side of the center.

The "square-root-of-raised-cosine" approach comes about as follows:

A raised cosine channel response satisfies requirement #2
above. Though it is not the only response to do so (anything with the
proper symmetry around 1/2 the data rate will do), it is the easiest
to implement and to model. In particular, a brick-wall filter that
cuts off precisely at 1/2 of the data rate will also do, but
brick-wall filters are notoriously impossible to realize in practice.

Second, if you take the square root of the raised cosine response and
implement it in both the transmitter and the receiver, then the
receiver's response will be matched to the transmitter's spectrum,
meeting requirement #1 above. Furthermore, the combination of the two
square-root responses, when multiplied together, gives the original
raised-cosine response, which continues to meet requirement #2.

This assumes that data bits are sent into the transmitter filter as
impulses of infinite amplitude and infintesmal duration. As such
impulses have a uniformly flat frequency spectrum, the spectrum of the
resulting signal will be that of a square root of raised cosine -- to
which the receiver filter is matched, because it also has a square
root of raised cosine response.

In a real transmitter that uses DSP, these impulses can be closely
approximated by single-sample impulses. E.g., if the sampling rate is
8x the bit rate (a common choice) then the data stream fed into the
transmitter filter might look like this:

-1 0 0 0 0 0 0 0 +1 0 0 0 0 0 0 0 -1 ...

where the data is bipolar (1 remains 1 and 0 becomes -1).

As an alternative (often done in hardware) the data signal is held for
the duration of each bit, e.g., 

-1 -1 -1 -1 -1 -1 -1 -1 +1 +1 +1 +1 +1 +1 +1 +1 -1 ...

In this case, the spectrum of the signal is *not* flat -- it has a sin(x)/x
shape, so you need a x/sin(x) correction factor in the transmitter filter.
The filter design programs often give this to you as an option, e.g.,
as a x/sin(x) * sqrt(raised cosine) response. My own preference so far
for DSP filters is to use the data impulse approach so the transmitter
and receiver filters can be identical.

Now all this assumes you have control over both the receiver and
transmitter.  But if you're designing a receiver for an arbitrary RTTY
transmitter, you're going to have to be more flexible. The transmitter
might not have been designed to have a square-root-of-raised-cosine
response. This means you'll generally have to use a suboptimum filter
(from a matched filter standpoint) at the receiver in order to
eliminate ISI on the desired signal, or vice versa. The demod *will*
work, but you'd have worse SNR performance than you'd like.

Alternatively, you could figure out what the transmitter filter looks
like, then make a matched filter at the receiver. This would leave
ISI, which you could take out with a Viterbi decoder (assuming the
duration of the ISI is not too great, which would otherwise entail a
Viterbi decoder with an impractical number of states).

Still another possibility is to build an equalizer to deal with the
nonideal transmitter filter, but this gets quite hairy and advanced.

This is why I personally find it more interesting to design new links
from scratch where I can control both ends of the link. Not only can I
make the frequency responses optimum, but I can add FEC and control
other aspects of the link protocol.

Phil

From ronald_evans@pipeline.com Mon Nov 18 23:35:09 1996
Received: from itchy.mindspring.com (itchy.mindspring.com [204.180.128.6]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA00127 for <hfsig@tapr.org>; Mon, 18 Nov 1996 23:35:07 -0600 (CST)
Received: from hal (user-37kb947.dialup.mindspring.com [207.69.164.135]) by itchy.mindspring.com (8.7.5/8.7.3) with SMTP id AAA27232 for <hfsig@tapr.org>; Tue, 19 Nov 1996 00:35:05 -0500 (EST)
Message-Id: <2.2.32.19961119053503.007033b0@pop.pipeline.com>
X-Sender: ronald_evans@pop.pipeline.com
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 19 Nov 1996 00:35:03 -0500
To: hfsig@tapr.org
From: "Ronald H. Evans" <ronald_evans@pipeline.com>
Subject: Clover and the P-38

Is this the place to discuss Clover, Pactor II, software to use with my P-38
and related topics?  I am especially interested in battery powered portable
operation of these modes.  Tnx,  Ron, K4KTB

From dts@dtsdata.intnet.bj Tue Nov 19 01:01:10 1996
Received: from newserver.dtsdata.intnet.bj (dtsdata.intnet.bj [194.51.163.246]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA11367 for <hfsig@tapr.org>; Tue, 19 Nov 1996 01:00:59 -0600 (CST)
Received: from [192.168.0.92] by newserver.dtsdata.intnet.bj (NTMail 3.01.03) id xa004235; Tue, 19 Nov 1996 07:01:16 +0200
Received: by newserver.dtsdata with Microsoft Mail
	id <01BBD5EF.C0226440@newserver.dtsdata>; Tue, 19 Nov 1996 08:00:38 +-100
Message-ID: <01BBD5EF.C0226440@newserver.dtsdata>
From: Peter Schulze <dts@dtsdata.intnet.bj>
To: "'hfsig@tapr.org'" <hfsig@tapr.org>
Subject: RE: [HFSIG:1724] Clover and the P-38
Date: Tue, 19 Nov 1996 08:00:32 +-100
Encoding: 10 TEXT
X-Info: EURAF/DTS Mail Server Cotonou

The IDRA reflector discussed these issues, check

http://dtsdata.intnet.bj/idra/newsub.htm

for details. Previous articles on that subject are archived at:

http://dtsdata.intnet.bj/idralog/subject.htm

73
Peter TY1PS

From alanb@polecat.sr.hp.com Tue Nov 19 15:41:15 1996
Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id PAA24433 for <hfsig@tapr.org>; Tue, 19 Nov 1996 15:41:13 -0600 (CST)
Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id NAA01327 for <hfsig@tapr.org>; Tue, 19 Nov 1996 13:41:11 -0800 (PST)
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA227429670; Tue, 19 Nov 1996 13:41:11 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA095919670; Tue, 19 Nov 1996 13:41:10 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611192141.AA095919670@polecat.sr.hp.com>
Subject: RTTY
To: hfsig@tapr.org
Date: Tue, 19 Nov 1996 13:41:10 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Phil Karn <karn@qualcomm.com> wrote:

> As an alternative (often done in hardware) the data signal is held for
>the duration of each bit, e.g., 
>
>-1 -1 -1 -1 -1 -1 -1 -1 +1 +1 +1 +1 +1 +1 +1 +1 -1 ...
>
>In this case, the spectrum of the signal is *not* flat -- it has a sin(x)/x
>shape, so you need a x/sin(x) correction factor in the transmitter filter.
...
>Now all this assumes you have control over both the receiver and
>transmitter.  But if you're designing a receiver for an arbitrary RTTY
>transmitter, you're going to have to be more flexible. The transmitter
>might not have been designed to have a square-root-of-raised-cosine
>response. This means you'll generally have to use a suboptimum filter
>(from a matched filter standpoint) at the receiver in order to
>eliminate ISI on the desired signal, or vice versa. The demod *will*
>work, but you'd have worse SNR performance than you'd like.
...
>Still another possibility is to build an equalizer to deal with the
>nonideal transmitter filter, but this gets quite hairy and advanced.

Most traditional RTTY transmitters get around the ISI problem simply by 
using a filter cutoff frequency much higher than needed.  This results 
in a wider transmitted bandwidth, but at 45 or 100 baud, who cares?  
Most receivers don't have a narrow enough crystal filter to make use of 
signals separated by 100 Hz anyway (and would have horrible group delay 
variation if they did.)

In designing the receiver, you wouldn't go far wrong to assume that 
there is no transmit filter and that each mark or space tone is held 
for the entire duration of the symbol as Phil illustrated above.  The 
receiver filter can include the sin(x)/x correction and a Nyquist filter 
convolved together into one set of filter coefficients to get a net 
almost-Nyquist response.

To generate the FIR filter coefficients, the easiest way would be to
multiply the raised-cosine frequency response with PI*x/sin(PI*x) and
do an inverse FFT on the result to get the impulse response, which is 
the FIR filter coeficients.  Then apply your favorite window function 
to truncate to the length of your filter.

Another refinement would be to cancel out the amplitude and group delay
variation in the receiver crystal filter.  You would like to use as
narrow a filter as possible to eliminate interference, but narrow 
analog filters add ISI.  To measure the filter response you could
generate a narrow RF pulse (use the Woodpecker as a test signal? :=) 
and use the demodulator's A/D to measure the impulse response.  The
reciprocal of that would then be convolved with the receiver filter
coefficients as determined above.  When is some manufacturer going to
design a demod with this feature built in?

Alan Bloom N1AL

From karn@qualcomm.com Tue Nov 19 23:10:13 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA20657 for <hfsig@tapr.org>; Tue, 19 Nov 1996 23:10:11 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id VAA02017; Tue, 19 Nov 1996 21:09:39 -0800 (PST)
Date: Tue, 19 Nov 1996 21:09:39 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199611200509.VAA02017@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199611152136.AA053593777@polecat.sr.hp.com> (message from Alan Bloom on Fri, 15 Nov 1996 15:43:42 -0600 (CST))
Subject: Re: [HFSIG:1711] SFDR

>By the way, the sampling rate must be > 2x the bandwidth, not 2x the
>frequency.  For example, if the IF frequency is 2.5 MHz, and the bandwidth

One comment here -- although the A/D converter can take its time when
the IF bandwidth is much less than the frequency, the sample-and-hold
used ahead of the A/D converter must still have a very short sample
time compared to the period of the RF waveform. As I understand it,
the sample-and-hold circuits are one of the limiting factors on the
performance of a digital radio that uses direct IF sampling.

Phil

From s56a@s55tcp.ampr.org Wed Nov 20 03:00:39 1996
Received: from s55tcp.ampr.org (ljutcp.hamradio.si [193.2.132.80]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id DAA09005 for <hfsig@tapr.org>; Wed, 20 Nov 1996 03:00:32 -0600 (CST)
Date: Wed, 20 Nov 96 08:56:31 EST
Message-Id: <14942@s55tcp.ampr.org>
From: Marijan Miletic <s56a@s55tcp.ampr.org>
Reply-To: S56A@s55tcp.ampr.org
To: hfsig@tapr.org
Subject: KISS explanations

Alan's, N1AL explanation of sigma-delta explanation reminded me of even simler
circuit diagram using comparator, D-type flip-flop and RC feedback in some old
Motorola book on telecommunicattion IC's.  Many DSP topics are explained in
straightforward fashion in TI application books while the others involve a lot
of math to fill the pages.  However, when the going gets tough, one has to
revert to abstract math :-)
73 de Mario, S56A, N1YU.

From alanb@polecat.sr.hp.com Wed Nov 20 12:38:31 1996
Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id MAA02356 for <hfsig@tapr.org>; Wed, 20 Nov 1996 12:38:28 -0600 (CST)
Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id KAA16575 for <hfsig@tapr.org>; Wed, 20 Nov 1996 10:38:22 -0800 (PST)
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA021345101; Wed, 20 Nov 1996 10:38:21 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA089115098; Wed, 20 Nov 1996 10:38:18 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611201838.AA089115098@polecat.sr.hp.com>
Subject: S/H
To: hfsig@tapr.org
Date: Wed, 20 Nov 1996 10:38:17 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Phil Karn <karn@qualcomm.com> wrote:

>>By the way, the sampling rate must be > 2x the bandwidth, not 2x the
>>frequency. 
>
>One comment here -- although the A/D converter can take its time when
>the IF bandwidth is much less than the frequency, the sample-and-hold
>used ahead of the A/D converter must still have a very short sample
>time compared to the period of the RF waveform. As I understand it,
>the sample-and-hold circuits are one of the limiting factors on the
>performance of a digital radio that uses direct IF sampling.

Good point.  That's probably why a lot of radios with digital IF's
go to the trouble of heterodyning down to a low IF frequency before
digitizing.  Designing a high-speed sample-and-hold is not trivial.

But the S/H is the only part that has to run at 2x the IF frequency.  
The A/D and the DSP can run at the lower rate (2x bandwidth).

Al N1AL

From rick@itron-ca.com Wed Nov 20 13:50:33 1996
Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA05887 for <hfsig@tapr.org>; Wed, 20 Nov 1996 13:50:31 -0600 (CST)
Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id LAA01247 for <hfsig@tapr.org>; Wed, 20 Nov 1996 11:50:13 -0800
Received: from unknown(204.30.20.214) by gate.itron-ca.com via smap (V1.3mjr)
	id sma001245; Wed Nov 20 11:49:39 1996
Date: Wed, 20 Nov 96 11:48:14    
From: Rick Booth <rick@itron-ca.com>
Subject: RE: [HFSIG:1729] S/H 
To: hfsig@tapr.org
X-PRIORITY: 3 (Normal)
X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc.
Message-ID: <Chameleon.848519590.rick@rickb.itron-ca.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

In spite of the fact the sampling process at the output of an IF 
can be performed at rates consistent with the BANDWIDTH there are 
certain s/h (and/or a/d) considerations that must account for the 
IF frequency being used, the most notable being the aperture 
jitter.  Aperture jitter translates into phase noise and is worse 
as the IF frequency is increased.  This is easily observed in a 
constellation plot at the output of a digital radio...good s/h's 
with low jitter look clean and lousy s/h's look noisy...no free 
lunch.
Rick
W6NZK
-------------------------------------
Rick Booth
'95 900SS SP

E-mail: rick@itron-ca.com
-------------------------------------

From k6sti@n2.net  Wed Nov 20 17:32:28 1996
Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA15291 for <hfsig@tapr.org>; Wed, 20 Nov 1996 17:32:24 -0600 (CST)
Received: from p154.n2.net (p154.n2.net [207.113.132.154]) by ravel.n2.net (8.6.12/8.6.12) with SMTP id PAA22647 for <hfsig@tapr.org>; Wed, 20 Nov 1996 15:34:31 -0800
Date: Wed, 20 Nov 1996 15:34:31 -0800
Message-Id: <199611202334.PAA22647@ravel.n2.net>
X-Sender: k6sti@mail.n2.net
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: k6sti@n2.net (Brian Beezley)
Subject: Re: [HFSIG:1730] RE: S/H 

>In spite of the fact the sampling process at the output of an IF 
>can be performed at rates consistent with the BANDWIDTH there are 
>certain s/h (and/or a/d) considerations that must account for the 
>IF frequency being used, the most notable being the aperture 
>jitter.  Aperture jitter translates into phase noise and is worse 
>as the IF frequency is increased.  This is easily observed in a 
>constellation plot at the output of a digital radio...good s/h's 
>with low jitter look clean and lousy s/h's look noisy...no free 
>lunch.
>Rick
>W6NZK
>-------------------------------------
>Rick Booth
>'95 900SS SP
>E-mail: rick@itron-ca.com
>-------------------------------------
>
>
>

I was wondering why the new radios with IF DSP use an 11-kHz or something
last IF.  Seemed crazy, but must be the S/H problem.


Brian Beezley, K6STI
k6sti@n2.net

From k5cnf1@juno.com  Wed Nov 20 19:08:29 1996
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA20049 for <hfsig@tapr.org>; Wed, 20 Nov 1996 19:08:25 -0600 (CST)
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail)
	id UAA16795; Wed, 20 Nov 1996 20:02:22 EST
To: hfsig@tapr.org
Date: Wed, 20 Nov 1996 06:58:35 PST
Subject: Re: TU-170
Message-ID: <19961120.070032.8279.0.k5cnf1@juno.com>
References: <19961118.110303.7879.1.w5zit@juno.com>
X-Mailer: Juno 1.00
X-Juno-Line-Breaks: 0-6,9-16,19-26,35-36,38-39,44-64
From: k5cnf1@juno.com (Richard B Morrow)



>Take a look at the filtering after the mark/space detector and see if 
>the
>output transitions are restricted to a slower rate.  You may have to
>decrease the value of one or more filter caps to get the higher data
>rates.
 Can you explain what I am going to look for? I got to thinking about it
and realized that I just might not have a clue... which is not unusual
at times.

>There are several packages that run RTTY from a PC that would require 
>no mod to the TU-170 at all - except for perhaps an adapter to get the
>RS-232 levels conditions for your PC.  I don't recall if the I/O of 
>the TU-170 is RS-232 compatable or just TTL - but you probably have all 
>the specs there in your docs.
  
this ne does not have the RS-232 output but I think that there were some mods to add that in the documentation I have.. Just have to look for it I
guess

>I have used an Amtor freebie program on HF with some success, and the
>TU-170 should work well on Amtor with the Baud filter modified to pass
>the 100 Baud data. On the other hand - if the Flesher specs say it was
>designed to pass 100 Baud RTTY signals - then no modification would be
>required for Amtor.

That would be a real deal if I could find it. My Rig is a TS-430 and I
can whip up just about anything to interface it. I am busy with repairs
on my motorcycle and car, Plus I am doing voulinteer work at the local
museum. Don't know if you have been seeing anything in your local paper
about the shipwreck in Matagorda Bay, The La Belle, which was one of the
La Salle expedition ships that went aground in 1686 or so. The cannon
that came up from that wreck was a real beauty. BUT I digress. I am doing the electronics  for the reverse electrolysis that gets the salt out of
the metal  out of whatever they pull out out of the slat water. 

I figure that the TU 170 could be used for just about anything with the
right program was to be had.

I do appreciate your input to the smoke testing that will be conducted
later when I get all of the stuff hooked up.. By the way what bands are you on any way I can be found on 7.213 at times, but right now I am sort of off the air while I move furnature in the shack so I can have anothe
desk to pile more stuff on and cover everything up even better..

73, Richard, K5CNF

>There is a program that can be purchased to run Pactor to an external
>modem also - which would require modifying the TU-170 Baud fliter to 
>pass
>the 200 Baud Pactor signals.  I do not recall the name of the program 
>-
>but I have worked several hams using it.
>
>Look on the QRZ CD Rom for programs that run on the PC to run various
>modes.  You may have some ham buddies who have that CD who can help.
>
>If you have trouble locating any of the specific programs - let me 
>know
>and I will see what I can dig up.
>
>73 - Jim - w5zit@juno.com
>
>

From lylej@azstarnet.com Wed Nov 20 22:59:15 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAA04032 for <hfsig@tapr.org>; Wed, 20 Nov 1996 22:59:10 -0600 (CST)
Received: from tomswift2 (usr5ip57.azstarnet.com [169.197.6.57]) by mailhost.azstarnet.com (8.8.2-pb2/8.8.2) with SMTP id VAA12822 for <hfsig@tapr.org>; Wed, 20 Nov 1996 21:56:24 -0700 (MST)
Date: Wed, 20 Nov 1996 21:56:24 -0700 (MST)
Message-Id: <1.5.4.32.19961120215749.00371cb8@pop.azstarnet.com>
X-Sender: lylej@pop.azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1732] Re: TU-170

Richard,

>That would be a real deal if I could find it. My Rig is a TS-430 and I
>can whip up just about anything to interface it. 

N7CL wrote up some mods that you'll want to do to your TS430S if you plan on
using it for AMTOR or any other fast switching mode between receive and
transmit.  It was in PSR several years ago.  I did it to my '430 back when I
owned one and it made the difference between being a useful rig for AMTOR
and a not very useful rig.

Cheers,

Lyle

From wd5ivd@tapr.org Thu Nov 21 01:50:33 1996
Received: from [128.83.113.72] (slip-a-8.ots.utexas.edu [128.83.113.72]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA18796 for <hfsig@tapr.org>; Thu, 21 Nov 1996 01:50:30 -0600 (CST)
Message-Id: <v03007806aeb99cbd4ec7@[128.83.176.153]>
In-Reply-To: <1.5.4.32.19961120215749.00371cb8@pop.azstarnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 20 Nov 1996 23:45:36 -0600
To: hfsig@tapr.org
From: "Greg Jones, WD5IVD" <wd5ivd@tapr.org>
Subject: Re: [HFSIG:1733] Re: TU-170

The index of articles is on the web page under PSR link on the top page
http://www.tapr.org  It is in XLS, CSV, and TXT formats.  Should be easy
enough to search and locate.

Cheers - Greg, WD5IVD


>Richard,
>
>>That would be a real deal if I could find it. My Rig is a TS-430 and I
>>can whip up just about anything to interface it.
>
>N7CL wrote up some mods that you'll want to do to your TS430S if you plan on
>using it for AMTOR or any other fast switching mode between receive and
>transmit.  It was in PSR several years ago.  I did it to my '430 back when I
>owned one and it made the difference between being a useful rig for AMTOR
>and a not very useful rig.
>
>Cheers,
>
>Lyle


-----
Greg Jones, WD5IVD
Austin, Texas
wd5ivd@tapr.org
http://www.tapr.org/~wd5ivd
-----


From lylej@azstarnet.com Thu Nov 21 09:03:05 1996
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA02449 for <hfsig@tapr.org>; Thu, 21 Nov 1996 09:03:02 -0600 (CST)
Received: from tomswift2 (usr6ip26.azstarnet.com [169.197.7.26]) by mailhost.azstarnet.com (8.8.3-p/8.8.2) with SMTP id IAA09167 for <hfsig@tapr.org>; Thu, 21 Nov 1996 08:00:17 -0700 (MST)
Date: Thu, 21 Nov 1996 08:00:17 -0700 (MST)
Message-Id: <1.5.4.32.19961121080143.0030bb7c@pop.azstarnet.com>
X-Sender: lylej@pop.azstarnet.com
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Lyle Johnson <lylej@azstarnet.com>
Subject: Re: [HFSIG:1734] Re: TU-170

At 01:56 AM 11/21/96 -0600, you wrote:
>The index of articles is on the web page under PSR link on the top page
>http://www.tapr.org  It is in XLS, CSV, and TXT formats.  Should be easy
>enough to search and locate.

Yep!  Jan '86, Issue 18, page 11.

From jtpjatae@bicc00.bi.ehu.es Thu Nov 21 12:42:51 1996
Received: from bicc00.bi.ehu.es (bicc00.bi.ehu.es [158.227.65.40]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA14478 for <hfsig@tapr.org>; Thu, 21 Nov 1996 12:42:02 -0600 (CST)
Received: from bipt71.bi.ehu.es by bicc00.bi.ehu.es (AIX 3.2/UCB 5.64/4.03)
          id AA38665; Thu, 21 Nov 1996 19:44:56 GMT
Message-Id: <9611211944.AA38665@bicc00.bi.ehu.es>
Comments: Authenticated sender is <jtpjatae@bicc00.bi.ehu.es>
From: "Eduardo Jacob" <jtpjatae@bicc00.bi.ehu.es>
Organization: ETSII y de IT, Bilbao, UPV/EHU
To: hfsig@tapr.org
Date: Thu, 21 Nov 1996 19:41:36 +0000
Subject: Spanish Article about EVM56002
Reply-To: jtpjatae@bicc00.bi.ehu.es
Priority: normal
X-Mailer: Pegasus Mail for Win32 (v2.42a)

I have just setup a page with an article written by Jabi EA2ARU 
and me. It is inspired in Johan's one and is going to be published
in a Spanish Amateur Magazine (I think) in December. It mentions 
the work of several people and it is meant to be a contribution 
to the spanish speaking ham comunity in order to help them beginning 
to play with the EVM. I think there will be another soon.

	The article is meant to be a living article so I welcome any 
comments about it. It is located at

	http://bipt.bi.ehu.es/~jtpjatae/articulo.html

	These pages are my first ones, so contributions and comments are 
welcome.

	Eduardo EA2BAJ

----------------
Eduardo Jacob - Area de Ingenieria Telematica
Departamento de Electronica y Telecomunicaciones
ETSII y de IT               Tel: +34-(9)4-427 8055
UPV / EHU                   Fax: +34-(9)4-441 4041
Alda Urquijo s/n         E-mail: jtpjatae@bi.ehu.es
E-48013 - Bilbao (Spain)       : 100021,2212 Compuserve
Ham: EA2BAJ          VHF PACKET: EA2BAJ @ EA2URV

From rwmcgwier@worldnet.att.net Thu Nov 21 20:30:39 1996
Received: from mtigwc02.worldnet.att.net (mailhost.worldnet.att.net [204.127.129.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA05921 for <hfsig@tapr.org>; Thu, 21 Nov 1996 20:30:35 -0600 (CST)
Received: from dad.ccr-p.ida.org ([207.116.39.164])
          by mtigwc02.worldnet.att.net (post.office MTA v2.0 0613 )
          with SMTP id AAA24037 for <hfsig@tapr.org>;
          Fri, 22 Nov 1996 02:30:19 +0000
Message-ID: <32950F6C.19D4@worldnet.att.net>
Date: Thu, 21 Nov 1996 21:26:52 -0500
From: Robert McGwier <rwmcgwier@worldnet.att.net>
Reply-To: rwmcgwier@worldnet.att.net
Organization: N4HY Software
X-Mailer: Mozilla 3.0Gold (Win95; I)
MIME-Version: 1.0
To: hfsig@tapr.org
Subject: Re: [HFSIG:1720] Sigma Delta
References: <199611182256.AA067387805@polecat.sr.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan Bloom wrote:
> 
> I promised to try to find a reference explaining Sigma-Delta A/D converters.
> None of my DSP textbooks seem to cover the topic.  I did find an app note
> from Harris Semiconductor (AN9504, May 1995) that does a pretty good job.
> I can copy it if anyone is interested.
> 
> Basically a sigma-delta converter is formed thus:
> 

What follows had all the elements, but hooked up incorrectly.
The one bit DAC output is integrated for a very short period of
time.  The output of the integrator is fed into the summer
where it is subtracted from the Analog Input.  This goes into
the comparator where the Digital output comes and the error
signal tells the DAC whether over the next period of integration
it should output plus or minus voltage.  Now it should make more
logical sense to you as it is doing proportional guidance with
bang bang control if you want to go look at an old control
theory book.  This is the simplest sigma-delta ADC.  They get
much fancier.

Bob

**************************************************************************
* Robert W. McGwier, Ph.D. * Mathematician. Hobbies: Computers,
Astronomy*
* 64 Brooktree Rd.         * Amateur Radio. Scouts: Council Commissioner
*
* East Windsor, NJ 08520   * Post 995 Advisor, Troop 5700 Advancement,  
*
* (H) 609-443-8963         * Sanhican #2 (Brotherhood), Used to be a    
*
* (F) 609-924-3061         * Buffalo (NE-III-120).  George Washington   
*
* (W) 609-279-6240         * Council.  Brownie Troop 193                
*
**************************************************************************

From alanb@polecat.sr.hp.com Fri Nov 22 14:30:09 1996
Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA26164 for <hfsig@tapr.org>; Fri, 22 Nov 1996 14:30:07 -0600 (CST)
Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id MAA01061 for <hfsig@tapr.org>; Fri, 22 Nov 1996 12:30:05 -0800 (PST)
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA211294605; Fri, 22 Nov 1996 12:30:05 -0800
Received: by polecat.sr.hp.com
	(1.37.109.16/15.5+ECS 3.3) id AA082054604; Fri, 22 Nov 1996 12:30:04 -0800
From: Alan Bloom <alanb@polecat.sr.hp.com>
Message-Id: <199611222030.AA082054604@polecat.sr.hp.com>
Subject: Re: Sigma Delta
To: hfsig@tapr.org
Date: Fri, 22 Nov 1996 12:30:04 -0800 (PST)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Robert McGwier <rwmcgwier@worldnet.att.net> wrote:

>Alan Bloom wrote:
>> 
>> I promised to try to find a reference explaining Sigma-Delta A/D converters.
>> None of my DSP textbooks seem to cover the topic.  I did find an app note
>> from Harris Semiconductor (AN9504, May 1995) that does a pretty good job.
>> I can copy it if anyone is interested.
>> 
>> Basically a sigma-delta converter is formed thus:
>> 
>
>What follows had all the elements, but hooked up incorrectly.
>The one bit DAC output is integrated for a very short period of
>time.  The output of the integrator is fed into the summer
>where it is subtracted from the Analog Input.  This goes into
>the comparator where the Digital output comes and the error
>signal tells the DAC whether over the next period of integration
>it should output plus or minus voltage.  Now it should make more
>logical sense to you as it is doing proportional guidance with
>bang bang control if you want to go look at an old control
>theory book.  This is the simplest sigma-delta ADC.  They get
>much fancier.

I think what you're describing is this:

Analog      __________      _____________
Input ---->|+         |    | Comparator  |
	   |  Summer  |--->| (1-bit A/D) |----*----> digital output
       +-->|-_________|    |_____________|    |
       |                                      |
       |    ____________      ___________     |
       |   |            |    |           |    |
       +---| Integrator |<---| 1-bit D/A |<---+
           |____________|    |___________|

That is actually a "Delta" converter.  Compared to a Sigma-Delta
converter it has the disadvantage that there is a slew rate limit
on the input signal.  A high-amplitude, high-frequency analog input
will exceed the slew rate capability of the integrator, causing
severe distortion.  That's not too serious a constraint for codec
applications, because most of the energy in the human voice is at
low frequencies.  The high-frequency energy is low enough not to
exceed the maximum slew rate.


It's called a "Delta" converter because the digital output represents
the rate of change (delta) at the input.  A continuous DC input voltage 
causes the digital output to represent zero volts (+1 half the time, 
-1 half the time).  To recover the audio, you have to integrate the 
output (run it through a -6 dB per octave filter).

Another way to view the slew-rate problem is to note that the digital
output represents the slope (time rate of change) of the input signal.
The slew rate limit is the point where the output is all +1's or -1's.

In a Sigma-Delta converter, the integrator is moved from the input 
to the output of the summer.  That solves the slew rate problem and 
gives a flat output frequency response.

Alan Bloom N1AL

From rwhiting@winternet.com Fri Nov 22 18:12:37 1996
Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA05891 for <hfsig@tapr.org>; Fri, 22 Nov 1996 18:12:34 -0600 (CST)
Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id SAA09966 for <hfsig@tapr.org>; Fri, 22 Nov 1996 18:12:32 -0600 (CST)
Date: Fri, 22 Nov 1996 18:12:32 -0600 (CST)
Posted-Date: Fri, 22 Nov 1996 18:12:32 -0600 (CST)
Message-Id: <199611230012.SAA09966@icicle.winternet.com>
Received: from ppp-67-24.dialup.winternet.com(204.246.67.24) by icicle.winternet.com via smap (V2.0beta)
	id xmab09788; Fri, 22 Nov 96 18:12:08 -0600
X-Sender: rwhiting@mail.winternet.com
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: Rick Whiting <rwhiting@winternet.com>
Subject: Re: Sigma Delta

There is a discussion of sigma-delta converters in:

   Pohlmann, K.C. (1991). "Advanced Digital Audio." Carmel, IN: SAMS

e.g., p. 407-408, 413-414. For example, there is an internal block diagram
of a DSP56ADC16 sigma-delta A/D converter on p. 413.

Regards/ Rick W0TN
 ------------------------------------------------------------------------
  Richard A. (Rick) Whiting          Home Phone: + 1 612 550 1213
  RF Engineer, AirTouch Cellular     Work Phone: + 1 612 595 5065
  5780 Rosewood Ln. N.               E-mail: rwhiting@winternet.com
  Plymouth, MN 55442-1411            Packet: W0TN @ WB0GDB.MN.USA.NOAM
 ------------------------------------------------------------------------

From karn@qualcomm.com Mon Nov 25 23:42:37 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA20183 for <hfsig@tapr.org>; Mon, 25 Nov 1996 23:42:34 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id VAA27906; Mon, 25 Nov 1996 21:42:02 -0800 (PST)
Date: Mon, 25 Nov 1996 21:42:02 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199611260542.VAA27906@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199611192141.AA095919670@polecat.sr.hp.com> (message from Alan Bloom on Tue, 19 Nov 1996 15:45:48 -0600 (CST))
Subject: Re: [HFSIG:1726] RTTY

>In designing the receiver, you wouldn't go far wrong to assume that 
>there is no transmit filter and that each mark or space tone is held 
>for the entire duration of the symbol as Phil illustrated above.  The 

If this is true, then the transmitted spectrum would have a "comb"
(sin(x)/x) shape and the simplest matched filter would be an
integrate-and-dump.

That is, if you can form a local estimate of the mark and space tones,
simply multiply the incoming signal separately by the local mark &
space estimates, square each to compute power, subtract one from the
other and integrate the result over the bit interval. Sample at the
end of the bit interval and you have your decision variable.

In other words, integrate

	cos(2*pi*fmark*t)*s(t))**2 - cos(2*pi*fspace*t)*s(t))**2 

over the bit interval. If the result is positive, you have a mark. If
negative, you have a space. Or you can use the numerical result as a
soft decision sample for a Viterbi decoder. Dump the accumulated value
and start again at 0 for the next bit.

This is a classic optimum noncoherent demodulator, with the signal
pulse shaping omitted because it's square to begin with.  Note that
you don't need knowledge of mark & space phase, only their frequencies,
and then only accurately enough so that the phase "drift" over a bit
interval is acceptably small. The faster the data rate, the sloppier
your frequency estimate can be.

Phil

From karn@unix.ka9q.ampr.org Tue Nov 26 05:39:51 1996
Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA06984 for <hfsig@tapr.org>; Tue, 26 Nov 1996 05:39:49 -0600 (CST)
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id DAA02000; Tue, 26 Nov 1996 03:39:39 -0800 (PST)
Date: Tue, 26 Nov 1996 03:39:39 -0800 (PST)
Message-Id: <199611261139.DAA02000@unix.ka9q.ampr.org>
From: Phil Karn <karn@unix.ka9q.ampr.org>
To: hfsig@tapr.org
In-reply-to: <199611260542.VAA27906@servo.qualcomm.com> (karn)
Subject: Re: [HFSIG:1740] Re: RTTY

A correction. The optimum noncoherent demodulator should integrate
the following over the bit interval:

	cos(2*pi*fmark*t)*s(t))**2 + sin(2*pi*fmark*t)*s(t))**2
	- [cos(2*pi*fspace*t)*s(t))**2 + sin(2*pi*fspace*t)*s(t))**2 ]

That is, the mark detector should produce the sum of the energies
received in both the in-phase and quadrature channels with respect
to the mark carrier reference, and similarly with the space detector.

The decision variable is, as before, the difference between the total
energies seen in these two channels over the bit interval.

By the way, the matched filter detector can be implemented in one
of two ways. 

The first way is to sample the output of a bandpass filter whose
response is the complex conjugate of the signal spectrum. "Complex
conjugate" simply means that the amplitude response is the same, and
the phase response is adjusted to correct for any frequency dispersion
in the signal.

The second way is to multiply the incoming signal by a local
time-reversed replica of the signal's nominal pulse shape, integrate
over a bit interval, then sample. (If the nominal pulse shape is
symmetrical, then the time-reversal isn't noticeable).

These two ways are in fact exactly equivalent. This is most easily
seen when you use a FIR (finite impulse response) filter to implement
method #1, as it does exactly the same thing as method #2 --
multiplying the incoming signal by the time-reversed replica of the
nominal pulse shape and summing (integrating) the results.

Phil


From Robert.Glassey@nmp.nokia.com Tue Nov 26 23:47:05 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id XAA22144 for <hfsig@tapr.org>; Tue, 26 Nov 1996 23:47:03 -0600 (CST)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id HAA29466 for <hfsig@tapr.org>; Wed, 27 Nov 1996 07:25:20 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.20/16.2) id AA143582238; Wed, 27 Nov 1996 07:23:58 +0200
X-Openmail-Hops: 2
Date: Tue, 26 Nov 96 13:37:55 +0000
Message-Id: <H000029202dadbaf@MHS>
In-Reply-To: <199611261139.DAA02000@unix.ka9q.ampr.org>
Subject: [HFSIG:1741] Re: RTTY
Mime-Version: 1.0
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII; name="[HFSIG:1741]"
Content-Transfer-Encoding: 7bit

> A correction. The optimum noncoherent demodulator should integrate
> the following over the bit interval:
> 
>  cos(2*pi*fmark*t)*s(t))**2 + sin(2*pi*fmark*t)*s(t))**2
>  - [cos(2*pi*fspace*t)*s(t))**2 + sin(2*pi*fspace*t)*s(t))**2 ]
> 
> That is, the mark detector should produce the sum of the energies
> received in both the in-phase and quadrature channels with respect
> to the mark carrier reference, and similarly with the space detector.

This sounds better, I was a bit confused by your pervious post. I have
implimented something similar in BTL for the 'Narrow' mode. But instead
of summing the squares of I and Q, I simple take the magnitude of I+jQ,
and compare the magnitudes. This would not be as good for a soft
decision variable, but it has no effect on the result of a hard decision
comparison between mark and space, ie is |A|>|B| then A*A > B*B. Since
RTTY has no way of detecting errors, this seems optimal to me.

However in actual practice, I find this method is rarely any better than
my non-optimnal detection, which simply uses +/- 100Hz filters (+/-170Hz
nulls) and takes the amplitude, then does the bit period intergration.
My overall receiver filter impulse is fairly rounded, complete with ISI,
and suffers from amplitude detection between the filter and the bit
period integrator, but still, it actually appears to work just as well
as the optimum solution, better if practicalities of tuning, listening
to several stations with slightly different frequencies, and the
170/200Hz shift uncertianty, are considered.

I suspect the lower tollerance to tuning of the optimal detection method
means that if the optimal method is slightly off tune, by say 20Hz, then
you have lost the few dB you might have gained, where the non-optimal
solution can work OK +/-75Hz off, looseing a few more dB of course, but
less than you would have lost with narrower filters.

If the optimal solution is more sensitive, in practice it makes little
difference given the fading nature of the channel, and the tuning
uncertainties. I have only ever got a significant improvement in
performance using the optimal filters when there as another RTTY signal
on the same frequency (shifted by maybe 50Hz) where I was able to filter
it out. Of course its very rear that this can be done.

Cheers,

Rob

From karn@qualcomm.com Wed Nov 27 01:42:27 1996
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA03860 for <hfsig@tapr.org>; Wed, 27 Nov 1996 01:42:25 -0600 (CST)
Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id XAA01372; Tue, 26 Nov 1996 23:41:54 -0800 (PST)
Date: Tue, 26 Nov 1996 23:41:54 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199611270741.XAA01372@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <H000029202dadbaf@MHS> (Robert.Glassey@nmp.nokia.com)
Subject: Re: [HFSIG:1742] Re: RTTY

>This sounds better, I was a bit confused by your pervious post. I have
>implimented something similar in BTL for the 'Narrow' mode. But instead
>of summing the squares of I and Q, I simple take the magnitude of I+jQ,
>and compare the magnitudes. This would not be as good for a soft

"Taking the magnitude of I+jQ" normally implies taking the sum of the
squares of the real and imaginary components, but from the later
context I assume you mean simply summing the amplitudes of the real
and imaginary components without any squaring operation?

If so, this is suboptimal even in an uncoded hard-decision
situation. Consider the following example in which your demodulator
algorithm makes an error while the optimal one does not:

Assume the mark channel integrator gives the complex result .707 +
.707j while the space channel integrator gives the result 1.3 +
0.0j. The space channel clearly has the stronger signal with magnitude
sqrt(1.3**2 + 0**2) = 1.3 as compared to the mark channel's
sqrt(.707**2 + .707**2) = 1.0. Yet your algorithm would give a
magnitude of 1.414 for the mark channel, causing it to be chosen in
error over the space channel.

Phil

From Robert.Glassey@nmp.nokia.com Thu Nov 28 04:04:14 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAA11050 for <hfsig@tapr.org>; Thu, 28 Nov 1996 04:04:12 -0600 (CST)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAA04707 for <hfsig@tapr.org>; Thu, 28 Nov 1996 12:03:35 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.20/16.2) id AA176045329; Thu, 28 Nov 1996 12:02:09 +0200
X-Openmail-Hops: 2
Date: Thu, 28 Nov 96 10:00:04 +0000
Message-Id: <H000029202dff828@MHS>
Subject: Re: RTTY
Mime-Version: 1.0
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII; name="Re:"
Content-Transfer-Encoding: 7bit

> Assume the mark channel integrator gives the complex result .707 +
> .707j while the space channel integrator gives the result 1.3 +
> 0.0j. The space channel clearly has the stronger signal with magnitude
> sqrt(1.3**2 + 0**2) = 1.3 as compared to the mark channel's
> sqrt(.707**2 + .707**2) = 1.0. Yet your algorithm would give a
> magnitude of 1.414 for the mark channel, causing it to be chosen in
> error over the space channel.

Sorry, yes, I agree. Perhaps I didn't explain clearly enough. The
amplitude I use is the magnitude of the complex vector ie sqrt(I*I +
Q*Q), although in actual practice I use a much faster approximation
which is accurate to about 1%. If I were to use squares I would need to
use 32 bit words or floating point, and there is no advantage for hard
decisions. I can always square the magnitude later if needed, and ovoid
carrying around 32 bit or floating point variables.

Cheers,
Rob

From s56a@s55tcp.ampr.org Thu Nov 28 06:12:41 1996
Received: from s55tcp.ampr.org (ljutcp.hamradio.si [193.2.132.80]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id GAA14403 for <hfsig@tapr.org>; Thu, 28 Nov 1996 06:12:39 -0600 (CST)
Date: Thu, 28 Nov 96 12:05:27 EST
Message-Id: <20383@s55tcp.ampr.org>
From: Marijan Miletic <s56a@s55tcp.ampr.org>
Reply-To: S56A@s55tcp.ampr.org
To: hfsig@tapr.org
Subject: Re: RTTY

Following my previous KISS postings, it is well known that IQ power can be also
calculated as sum of larger signal with 0.4 of smaller.  I use right shift for
1/2 of smaller signal...
73 de Mario, S56A, N1YU.

From Robert.Glassey@nmp.nokia.com Thu Nov 28 12:24:12 1996
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA27465 for <hfsig@tapr.org>; Thu, 28 Nov 1996 12:24:10 -0600 (CST)
From: Robert.Glassey@nmp.nokia.com
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA19560 for <hfsig@tapr.org>; Thu, 28 Nov 1996 20:23:34 +0200
Received: from  by samail01.nmp.nokia.com with SMTP
	(1.37.109.20/16.2) id AA214725328; Thu, 28 Nov 1996 20:22:08 +0200
X-Openmail-Hops: 2
Date: Thu, 28 Nov 96 18:20:23 +0000
Message-Id: <H000029202dff83a@MHS>
In-Reply-To: <20383@s55tcp.ampr.org>
Subject: [HFSIG:1745] Re: RTTY
Mime-Version: 1.0
Sender: Robert.Glassey@nmp.nokia.com
To: hfsig@tapr.org
Content-Type: text/plain; charset=US-ASCII; name="[HFSIG:1745]"
Content-Transfer-Encoding: 7bit

> Following my previous KISS postings, it is well known that IQ power
> can be also calculated as sum of larger signal with 0.4 of smaller.  I
> use right shift for 1/2 of smaller signal...

Sounds nice an simple!

Here's my one

I=abs(I)
Q=abs(Q)
if (Q>I) swap I and Q

If (Q>I/2) M = I*7/8 + Q*9/16
else M= I + Q/4

Shift and adds are used for the fractions.

My ASM code for this takes 0.9uS on my 486DX-2 / 80MHz


For phase:

phase = table[Q/(I+Q], for 0-45 degrees.

256 entries in table for 45 degrees

The Q/(I+Q) is an approximate phase to get reasonable linearity for the
table index, and the table values are 16 bits, used as a correction
table. Thus there are 256*8=2048 discernible phases.

I haven't done timing for this, but I expect it is faster than the ABS
function, since there are no shift and adds, but one multiply.


Cheers,

Rob

